Keyboard Shortcuts
Likes
Search
TK4- complaints with IEA994A ALL SYS1.DUMP DATA SETS ARE FULL
Dear Forum,
can this message be ignored and if not, how do I get empty SYS1.DUMP datasets? Is there a command or utility or job??
?
kind regards
Michael
--
TK5? ? ? ? on Raspberry Pi 5 with Raspberry OS "bookworm"
TK4-? ? ? on Raspberry Pi 5 with Raspberry OS "bookworm"
VM/370 on Raspberry Pi 5 with Raspberry OS "bookworm" Lime and limpid green, a second scene Now fights between the blue you once knew Floating down, the sound resounds Around the icy waters underground Jupiter and Saturn, Oberon, Miranda and Titania Neptune, Titan, stars can frighten (Syd Barrett of Pink Floyd) |
You could clear the dump datasets if you don't want to diagnose them--something like ?DD CLEAR,DSN=(ALL) or you can go one-by–one with DSN=(01) etc. Everything else should keep running normally, until you find you actually want a dump dataset :-) Roops On Thu, 3 Oct 2024, 10:36 Michael Grom via , <macbaer=[email protected]> wrote:
|
Or it's possible you will need to clear them the hard way, using JCL something like //? ?EXEC PGM=IEBGENER //SYSUT1 DD DUMMY //SYSUT2 DD DISP=OLD,DSN=SYS1.DUMP01 and probably with sensible DCB parameters for the DD cards. Roops On Thu, 3 Oct 2024, 11:40 Rupert Reynolds via , <rupertreynolds=[email protected]> wrote:
|
Dear Rupert,
I'm afraid I'm stuck. The system does not come up. Maybe I can do something with the dasd tools?? ?
12:56:31 HHC02264I Script 1: file scripts/ipl.rc processing ended
12:56:31 /*IEA994A ALL SYS1.DUMP DATA SETS ARE FULL AND NO SVC DUMPS CAN BE TAKEN 12:56:31 /*IEE479W MASTER SCHEDULER FAILED, REIPL 12:56:31 / IEE136I ?TIME=12.56.30 DATE=24.277 12:56:31 HHC02263I Script 4: processing resumed... 12:56:31 /d t 12:56:31 HHC02264I Script 4: file scripts/SCR00010A processing ended 12:56:31 / IEE136I ?TIME=12.56.31 DATE=24.277 12:56:33 HHC00107I Starting thread cckd_writer() from cckd_writer(), active=1, started=1, max=2 12:56:33 HHC90020W 'hthread_setschedparam()' failed at loc=cckddasd.c:1773: rc=22: Invalid argument 12:56:33 HHC00100I Thread id 000071014d7d76c0, prio 0, name 'cckd_writer thread 2' started ?
?
--
TK5? ? ? ? on Raspberry Pi 5 with Raspberry OS "bookworm"
TK4-? ? ? on Raspberry Pi 5 with Raspberry OS "bookworm"
VM/370 on Raspberry Pi 5 with Raspberry OS "bookworm" Lime and limpid green, a second scene Now fights between the blue you once knew Floating down, the sound resounds Around the icy waters underground Jupiter and Saturn, Oberon, Miranda and Titania Neptune, Titan, stars can frighten (Syd Barrett of Pink Floyd) |
Is that happening at IPL time, or later? In any event, your problem is not that all SYS1.DUMP datasets are full, but that the master scheduler is ABENDing. If you post more of the system log, we might be able to spot what's happening. On Thu, Oct 3, 2024 at 6:00?AM Michael Grom via <macbaer=[email protected]> wrote:
--
Jay Maynard |
开云体育Michael, Remember, Google is your friend – Ask – Google – MVS SYS1.DUMP? - you will be presented several choices – once says specifying and controlling – Now – in fairness – this is for current Z/os 3.1 – but for most commands it will get you either exactly or close enough to get the information you need. ? Try it – ? ?
-J- ? Jeff Bassett (301) 424-3362 (office) (240) 388-7148 Cell ? Time spent flying? - is NOT deducted from one’s lifespan ? From: [email protected] <[email protected]>
On Behalf Of Michael Grom via groups.io
Sent: Thursday, October 3, 2024 5:36 AM To: [email protected] Subject: [H390-MVS] TK4- complaints with IEA994A ALL SYS1.DUMP DATA SETS ARE FULL ? Dear Forum, can this message be ignored and if not, how do I get empty SYS1.DUMP datasets? Is there a command or utility or job?? ? kind regards Michael -- TK5? ? ? ? on Raspberry Pi 5 with Raspberry OS "bookworm" TK4-? ? ? on Raspberry Pi 5 with Raspberry OS "bookworm" (Syd Barrett of Pink Floyd) |
Hi Jay,
first of all, my apologies for kind of cross posting the problem also to the hercules group. I was not sure if the problem was related to MVS (aka "SYS1.DUMP FULL") or Hercules itself. Now that I transferred the dasd directory as a zip archive instead of each dasd image individually via scp (with wildcard) everything went back to normal.? ?
?
--
TK5? ? ? ? on Raspberry Pi 5 with Raspberry OS "bookworm"
TK4-? ? ? on Raspberry Pi 5 with Raspberry OS "bookworm"
VM/370 on Raspberry Pi 5 with Raspberry OS "bookworm" Lime and limpid green, a second scene Now fights between the blue you once knew Floating down, the sound resounds Around the icy waters underground Jupiter and Saturn, Oberon, Miranda and Titania Neptune, Titan, stars can frighten (Syd Barrett of Pink Floyd) |
Hi, Use command : DD CLEAR,DSN=ALL Ciao, On Thu, Oct 3, 2024 at 11:36?AM Michael Grom via <macbaer=[email protected]> wrote:
|
Oh my, You are right. I've been using it for so many years that I thought it was a very basic MVS command. I googled for an MVS 38 Command reference but to no avail. Any link would be greatly appreciated. TIA On Sun, Oct 13, 2024 at 4:34?PM Rob Prins via <prin0096=[email protected]> wrote:
|
On 5/10/2024 3:08 am, Raphael Dal Pos via groups.io wrote:
Use command : DD CLEAR,DSN=ALLIf I had to guess, I'd say the DUMPDS (or DD for short) command came in with MVS/XA. Also with MVS/XA blocking for SYS1.PARMLIB (definitely) and SYS1.DUMPxx (probably) were also allowed. These days dump data sets have RECFM=FBS, and the LRECL is not longer than MVS 3.8's 4104. Most records are used to contain the image of a virtual storage page and of course some header information with virtual storage address and ASID data is also required. 64-bit addressing is one obvious cause for the LRECL getting a bit longer - maybe it is 4160 these days. Dumps from MVS/XA could be much bigger so the trend went away from printed dumps to enhancing IPCS. The AMDPRDMP service aid was done away with and to reduce IPCS I/O, blocking was supported. SYS1.DUMP data sets are sequential data sets with fixed-length records. When a dump is stored into them, the VTOC entry is not updated, so they still appear to be empty to most utilities even when they contain a dump. To empty them for reuse, they need to be initialized with an EOF marker or an empty first track. Most sites added their own started task to SYS1.PROCLIB which used IEBGENER to copy in a DUMMY data set to the SYS1.DUMP data set (with the suffix set by command/JCL symbol). From the console you can issue DISPLAY DUMP (or D D for short) to display dump data set status. You might prefer to issue D D,L=Z to avoid the need for a subsequent K E,D if using a 3270 console. D D defaults to D D,S (or DISPLAY DUMP,STATUS for long). D D,O displays dump settings. On TSO, IPCS supplies the SYSDSCAN TSO command. For example, on my system the TSO command sysdscan 00:02 yields the following output: SYS1.DUMP00 IS EMPTY DATA SET SYS1.DUMP01 NOT IN CATALOG OR CATALOG CAN NOT BE ACCESSED DATA SET SYS1.DUMP02 NOT IN CATALOG OR CATALOG CAN NOT BE ACCESSED If SYS1.DUMP00 contained a dump, it would have displayed the dump title. If I edit SYS1.DUMP00 to add a record record with some text and then issue SYSDSCAN 00 I get NO TITLE RECORD FOUND FOR SYS1.DUMP00 An easy way to empty a SYS1.DUMP data set that contains a dump is by using the PDS command.? For example pds 'sys1.dump00' fix reset will empty SYS1.DUMP00.? (Yes, the PDS command can process sequential data sets too!) On z/OS dump data sets are not pre-defined but are allocated (created) dynamically. When I get an SVC or SYSMDUMP dump from a customer to look at, the first thing I do is browse it and scroll right until I see the z/OS release indicator (in text) in the first record so I know which IPCS environment to use so that the z/OS release of IPCS matches the z/OS release of the customer's system.? I am hardly an IPCS expert (wish I was better), but I can usually find what I need in the dump.? I have not tried IPCS on MVS 3.8 at all.? For z/OS, IPCS is an ISPF application (although it still work from READY I presume), but it's a bit more primitive on MVS 3.8 I'll bet. Anyway, that's my dump data set trivia... Cheers, Greg |
Thanks Greg for the explanation and history. I'll try the IEBGENER proc on my TK5 when I have time. Ciao, On Tue, Oct 15, 2024 at 3:52?PM Greg Price via <procegrog=[email protected]> wrote: On 5/10/2024 3:08 am, Raphael Dal Pos via wrote: |
I seem to be having a "similar" problem, at least as far as SYS1.DUMP being full.
?
On Thu, Oct 3, 2024 at 09:40 AM, Rob Prins wrote:
S CLRDMP,DUMP=DUMP00 For TK4- I get the following:
?
? ? - ? ? ? ? ? S CLRDMP,DUMP=DUMP00 ? ? ? ? ? ? ? ? ? ? ? ??
? ? ? STC ?778 ?$HASP100 CLRDMP ? ON STCINRDR ? ? ? ? ? ? ? ? ? ? ? STC ?778 ?IEF452I CLRDMP ? JOB NOT RUN - JCL ERROR ? ?? ? ? - STC ?778 ?$HASP396 CLRDMP ? TERMINATED ? ? ? ? ? ? ? ?? ? ? ? STC ?778 ?$HASP150 CLRDMP ? ON PRINTER2 ? ? ? ? 8 LINES ? ? ? ? ? ? ? ? IEE122I START COMMAND JCL ERROR ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? $HASP160 PRINTER2 INACTIVE - CLASS=Z ? ? ? ?? ? ? ? STC ?778 ?$HASP250 CLRDMP ? IS PURGED ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? $HASP000 OK ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
My log looks like the following. I've not done much of any work on this system other than to leave it up and running "idle" since I started recovering my KVMs from a server crash a while ago. I'm tired, so be kind. I think something happened to NJE38 and it finished filling SYS1.DUMP, so I probably need to go look at a dump to see what happened to NJE38? Trying Rob's suggestion and it not working means I need to go look at CLRDMP and see what is wrong with the JCL.
?
/16.22.48 ? ? ? ? ? LGN001I TSO logon in progress at VTAM terminal CUU0C0 ? ? ? ? ? ? ? ? ? ? ?
/16.22.57 TSU ? 68 ?$HASP100 XMAS ? ? ON TSOINRDR ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? /16.22.57 TSU ? 68 ?$HASP373 XMAS ? ? STARTED ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? /16.23.01 ? ? ? ? ? LGN001I TSO logon in progress at VTAM terminal CUU0C1 ? ? ? ? ? ? ? ? ? ? ? /16.23.11 TSU ? 69 ?$HASP100 HERC01 ? ON TSOINRDR ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? /16.23.11 TSU ? 69 ?$HASP373 HERC01 ? STARTED ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? /08.21.03 STC ?775 ?NJE38 ? ? LMOD NJEINIT ? ABEND S522 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? /08.21.03 STC ?775 ?PSW ? 00000000 00000000 ?ILC 00 ?INTC 0000 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? /08.21.03 STC ?775 ?DATA NEAR PSW ?00000000 ?040C0000 0002E19A 00000000 00000000 ? ? ? ? ? ? ?? /08.21.03 STC ?775 ?GR 0-3 ? 009BC7B0 ?88522000 ?00000000 ?009BE150 ? ? ? ? ? ? ? ? ? ? ? ? ? ? /08.21.03 STC ?775 ?GR 4-7 ? 00FE0898 ?009BC070 ?00000000 ?00000522 ? ? ? ? ? ? ? ? ? ? ? ? ? ? /08.21.03 STC ?775 ?GR 8-11 ?009BC7B0 ?00000000 ?00014058 ?009BC7B0 ? ? ? ? ? ? ? ? ? ? ? ? ? ? /08.21.03 STC ?775 ?GR 12-15 400663F2 ?009BC920 ?500665B6 ?00038CA0 ? ? ? ? ? ? ? ? ? ? ? ? ? ? /08.21.03 STC ?777 ?$HASP100 DUMPFULL ON STCINRDR ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? /08.21.03 STC ?775 *IEA994A ALL SYS1.DUMP DATA SETS ARE FULL AND NO SVC DUMPS CAN BE TAKEN ? ?? /08.21.03 STC ?777 ?IEF452I DUMPFULL JOB NOT RUN - JCL ERROR ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? /08.21.03 STC ?777 ?$HASP396 DUMPFULL TERMINATED ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? /08.21.03 STC ?777 ?$HASP150 DUMPFULL ON PRINTER2 ? ? ? ? 8 LINES ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? /08.21.03 ? ? ? ? ? $HASP160 PRINTER2 INACTIVE - CLASS=Z ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? /08.21.03 STC ?777 ?$HASP250 DUMPFULL IS PURGED ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? /08.21.03 STC ?775 ?IEF450I NJE38 NJE38 - ABEND S522 U0000 - TIME=08.21.03 ? ? ? ? ? ? ? ? ? ?? /08.21.03 STC ?775 ?$HASP395 NJE38 ? ?ENDED ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? /08.21.03 STC ?775 ?$HASP150 NJE38 ? ?ON PRINTER2 ? ? ? ?70 LINES ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? /08.21.03 ? ? ? ? ? $HASP160 PRINTER2 INACTIVE - CLASS=Z ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? /08.21.03 STC ?775 ?$HASP250 NJE38 ? ?IS PURGED ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? /18.18.03 STC ?778 ?$HASP100 CLRDMP ? ON STCINRDR ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? /18.18.03 STC ?778 ?IEF452I CLRDMP ? JOB NOT RUN - JCL ERROR ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? /18.18.03 STC ?778 ?$HASP396 CLRDMP ? TERMINATED ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? /18.18.03 STC ?778 ?$HASP150 CLRDMP ? ON PRINTER2 ? ? ? ? 8 LINES ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? /18.18.03 ? ? ? ? ? $HASP160 PRINTER2 INACTIVE - CLASS=Z ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? /18.18.03 STC ?778 ?$HASP250 CLRDMP ? IS PURGED ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
?... Mark S. |
Why's it trying to take an SVC dump on a 522? For that matter, what's NJE38 waiting on for 30 minutes that it takes a 522 in the first place? Got a dataset conflict or something? Your dump datasets full condition is something?you need to take care of, and you need to look?at the CLRDUMP?and DUMPFULL?procs to see why they're taking JCL errors, but that's not your primary problem. On Sun, Jan 5, 2025 at 5:41?PM Mark A. Stevens via <marXtevens=[email protected]> wrote:
--
Jay Maynard |
On Sun, Jan 5, 2025 at 05:53 PM, Jay Maynard wrote:
Why's it trying to take an SVC dump on a 522? For that matter, what's NJE38 waiting on for 30 minutes that it takes a 522 in the first place? Got a dataset conflict or something?Google AI says: ?
The S522 abend is not a typical job time exceeded error, it's a job wait time exceeded. That is to say, the time allocated to wait in an SVC wait state was exceeded.
?
So I looked to see what NJE38 might be waiting on, and apparently I had not uncommented the links between my two MVS systems. I'm guessing it timed out waiting for a device that was never there.
?
[xmas@mvs-01 local]$ cat 03
# # TCPNJE #? #0091 tcpnje 2703 lnode=mvs1 rnode=mvs2 lport=31176 rport=31176 rhost=192.168.122.102 [xmas@mvs-01 local]$?
?
[xmas@mvs-02 local_conf]$ cat tcpnje?
# # TCPNJE #? #0091 tcpnje 2703 lnode=mvsr2 rnode=mvs1 lport=31176 rport=31176 rhost=192.168.122.101 [xmas@mvs-02 local_conf]$?
?
So I'm going to shutdown the two systems, uncomment those, IPL, and then try to fix the dump jobs.
?
Thank you Jay!
?
?... Mark S.
?
|
On Sun, Jan 5, 2025 at 05:41 PM, Mark A. Stevens wrote:
So this is a TK4- vs. TK5 thing, for those of you just tuning in. For TK4- you have:
?
? ? ?RFEVIEW ?SYS2.PROCLIB(CLEARDMP) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? COLUMNS 1 72?
? ? ?COMMAND ===> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?SCROLL ===> CS ? ? ?* **** TOP OF DATA ? ? ?000001 //CLEARDMP PROC DD=00 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? ? ? ?000002 //EMPTY ? EXEC PGM=IEBGENER ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? ? ? ?000003 //SYSPRINT DD ?DUMMY ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?000004 //SYSIN ? ?DD ?DUMMY ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?000005 //SYSUT1 ? DD ?DUMMY ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?000006 //SYSUT2 ? DD ?DISP=SHR,DSN=SYS1.DUMP&DD ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?* *** BOTTOM OF DATA *** ?
and for TK5 you have:
?
?RFEVIEW ?SYS1.PROCLIB(CLRDMP) - 1.00 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?COLUMNS 1 72?
?Command ===> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Scroll ===> CSR? ?* **** TOP OF DATA ?====== ?-CAUTION- ?PROFILE NOW SET TO CAPS ON ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?====== ?-CAUTION- ?PROFILE NOW SET TO NUM ?ON ?STD ? ? ? ? ? ? ? ? ? ? ? ? ? ?? ?000001 //CLRDMP ? ?PROC ?DUMP=DUMP00 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Y02006? ?000002 //DMP ? ? ? EXEC ?PGM=IEBGENER ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Y01980? ?000003 //SYSPRINT ?DD ? ?SYSOUT=A ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?000004 //SYSUT2 ? ?DD ? ?DSN=SYS1.&DUMP,DISP=OLD ? ? ? ? ? ? ? ? ? ? ? ?Y02006? ?000005 //SYSUT1 ? ?DD ? ?DUMMY ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? ?000006 //SYSIN ? ? DD ? ?DUMMY ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Y02006? ?* *** BOTTOM OF DATA *** ?
Running CLRDMP on TK4- fails because the job isn't there, I did look.
?
?... Mark S.
|
One other thing of note: An S522 ABEND is *exceedingly* uncommon for anything but a TSO session, where it's issued if the session has?been idle too long. Anywhere else, and it's almost certainly either an operator screwup, or less commonly, a programmer not realizing that he's doing something like trying to share a dataset that a long-running task like INTERCOMM?has allocated?as DISP=OLD. On Sun, Jan 5, 2025 at 7:41?PM Mark A. Stevens via <marXtevens=[email protected]> wrote:
--
Jay Maynard |
?
Solution: copy this procedure to SYS1.PROCLIB in TK4-.
This is the official IBM supplied procedure.
?
Cheers,
Rob |