Discussion:
dasdload - HHCDL123E SEQ invalid lrecl or blksz: lrecl=80 blksz=19040
(too old to reply)
Mike Stramba mikestramba@gmail.com [hercules-390]
2015-12-17 12:06:03 UTC
Permalink
Tested with Herc 3.12, 3.11

When I run dasdload -z -a mik001.3390.cntl mik001.3390, on the cntl
file below I'm getting :

HHCDL123E SEQ invalid lrecl or blksz: lrecl=80 blksz=19040

If I delete the blksize parameter (19040), it runs without error, but
then when the dasd is mounted and varied online in TK-4 I get : "NO
FREE SPACE"

# dvol mik001
# SERIAL UNIT ---ATTRIBUTES---- VSAM AVAIL -----TOTALS----
LARGEST-EXTENT 5 EXTS
# MOUNT USE DSCBS TRACKS EXT CYL CYL+TR TRACKS TRACKS
# MIK001 192 RESERVED PRIVATE OFF 47 VOLUME CONTAINS NO FREE SPACE

------------------------- mik001.3390.cntl -------------
MIK001 3390 *
# dsname --- method ------ units pri sec dir dsorg
recfm lrecl blksize keylen
HERC02.ABC01.TXT seq ABC.txt TRK 10 10 0 PS F
80 19040


----------------------- abc.txt ----------------
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ12
-------------------------------------------------
somitcw@yahoo.com [hercules-390]
2015-12-17 16:20:23 UTC
Permalink
Post by Mike Stramba ***@gmail.com [hercules-390]
Tested with Herc 3.12, 3.11
When I run dasdload -z -a mik001.3390.cntl mik001.3390, on the cntl
HHCDL123E SEQ invalid lrecl or blksz: lrecl=80 blksz=19040
If I delete the blksize parameter (19040), it runs without error, but
then when the dasd is mounted and varied online in TK-4 I get : "NO
FREE SPACE"
- - - remainder snipped - - -

DASDLOAD turns on the DIRF bit or DOS contamination bit in the
format 4 DSCB of the VTOC to indicate that DASDLOAD does not
maintain the OS disk free space.

Just run an IEFBR14 or other program to allocate and delete a
temporary data set and MVS will build the format 5 DSCB records
to describe the free space on the disk.

//STEPONLY EXEC PGM=IEFBR14
//X DD UNIT=3390,VOL=SER=MIK001,SPACE=(TRK,1)

I don't know why Hercules doesn't like your BLKSIZE.
It probably should be investigated by someone.
somitcw@yahoo.com [hercules-390]
2015-12-17 16:33:35 UTC
Permalink
Post by ***@yahoo.com [hercules-390]
I don't know why Hercules doesn't like your BLKSIZE.
It probably should be investigated by someone.
Could Hercules be complaining the really bad block size of
19,040 on a 3390 disk volume? I doubt it.

3390:
min-blksz max-blksz blocks-per-track
27,999 ... 56,664 ... 1
18,453 ... 27,998 ... 2
13,683 ... 18,452 ... 3


BLKSIZE=27920 gives a half of a track
BLKSIZE=18400 gives a third of a track
Mike Stramba mikestramba@gmail.com [hercules-390]
2015-12-17 17:54:38 UTC
Permalink
I ran this job :

//JUNK JOB CLASS=A,MSGCLASS=X,MSGLEVEL=(1,1),NOTIFY=HERC01
//S1 EXEC PGM=IEFBR14
//X DD DSN=TEMP,DISP=(NEW,DELETE),
// UNIT=3390,VOL=SER=TXT001,SPACE=(TRK,1)
//SYSPRINT DD SYSOUT=A

Getting :

JUNK S1 X - SPACE REQUESTED NOT AVAILABLE
JUNK S1 - STEP WAS NOT EXECUTED.
Post by ***@yahoo.com [hercules-390]
Post by Mike Stramba ***@gmail.com [hercules-390]
Tested with Herc 3.12, 3.11
When I run dasdload -z -a mik001.3390.cntl mik001.3390, on the cntl
HHCDL123E SEQ invalid lrecl or blksz: lrecl=80 blksz=19040
If I delete the blksize parameter (19040), it runs without error, but
then when the dasd is mounted and varied online in TK-4 I get : "NO
FREE SPACE"
- - - remainder snipped - - -
DASDLOAD turns on the DIRF bit or DOS contamination bit in the
format 4 DSCB of the VTOC to indicate that DASDLOAD does not
maintain the OS disk free space.
Just run an IEFBR14 or other program to allocate and delete a
temporary data set and MVS will build the format 5 DSCB records
to describe the free space on the disk.
//STEPONLY EXEC PGM=IEFBR14
//X DD UNIT=3390,VOL=SER=MIK001,SPACE=(TRK,1)
I don't know why Hercules doesn't like your BLKSIZE.
It probably should be investigated by someone.
Tim Gurner aardvark_65@yahoo.com [hercules-390]
2015-12-17 18:06:39 UTC
Permalink
//JUNK    JOB CLASS=A,MSGCLASS=X,MSGLEVEL=(1,1),NOTIFY=HERC01
//S1    EXEC PGM=IEFBR14
//X      DD DSN=TEMP,DISP=(NEW,DELETE),
//    UNIT=3390,VOL=SER=TXT001,SPACE=(TRK,1)
//SYSPRINT DD SYSOUT=A
JUNK S1 X - SPACE REQUESTED NOT AVAILABLE
JUNK S1 - STEP WAS NOT EXECUTED.
Should it be VOL=SER=MIK001 ?

Tim
somitcw@yahoo.com [hercules-390]
2015-12-17 18:47:14 UTC
Permalink
Post by Tim Gurner ***@yahoo.com [hercules-390]
//JUNK JOB CLASS=A,MSGCLASS=X,MSGLEVEL=(1,1),NOTIFY=HERC01
//S1 EXEC PGM=IEFBR14
//X DD DSN=TEMP,DISP=(NEW,DELETE),
// UNIT=3390,VOL=SER=TXT001,SPACE=(TRK,1)
//SYSPRINT DD SYSOUT=A
JUNK S1 X - SPACE REQUESTED NOT AVAILABLE
JUNK S1 - STEP WAS NOT EXECUTED.
Should it be VOL=SER=MIK001 ?
Tim
Is the disk volume really full?
If so, SPACE=(TRK,0) may work? I haven't tried it for fixing
the DASDM DIRF bit or the DOS contamination bit.

If the disk is not already full, you might want to print the
format 4 and 5 DSCBs to determine if either is damaged.
AMASPZAP DUMP CCHHR CCHHR or
IEHLIST LISTVTOC DUMP

P.S. A temporary DSN is the default so DSN=TEMP not required.
The default DISP is (NEW,DELETE,DELETE) so not required.
IEFBR14 does not require a SYSPRINT DD statement.
None hurt except to add confusion.
Gerhard Postpischil gerhardp@charter.net [hercules-390]
2015-12-17 19:14:36 UTC
Permalink
I've had poor success using IBM methods. I have a procedure and some
data to ZAP the format 4, allocate, and ZAP it again to reset the
contaminated/bit. But I don't recall ever running it against a
completely full pack. Perhaps changing the DD DD to TRK,0 may work.

//FIXPACK PROC VS=VOLSER,DEV='SYSALLDA'
//*
//* THIS IS A SYSTEMS PROCEDURE
//* ACCOUNT=Z904
//*
//* THIS PROCEDURE WILL ATTEMPT TO CLEAN UP SOME VTOC ERRORS WHICH
//* RESULT FROM SYSTEM CRASHES DURING A VTOC UPDATE. THE JOB WILL
//* FAIL ON A JCL ERROR IF THE VOLUME IS TOO FRAGMENTED TO PERMIT
//* CLEANUP. THIS JOB SHOULD BE RUN WHEN NO OTHER JOBS WILL ACCESS
//* THE SAME PACK. PLEASE CONSULT SYSTEMS IF THE PACK STILL IS BAD
//* AFTER THIS RUN.
//*
//*
//ZAP EXEC PGM=AMASPZAP
//STEPLIB DD DSN=SYS1.ESPLIB,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSLIB DD VOL=SER=&VS,UNIT=&DEV,DISP=OLD,DSN=FORMAT4.DSCB
//SYSIN DD DSN=GERHARD.MVS.ESPPARM(F4ZAPDOS),DISP=SHR
//*
//PAP EXEC PGM=AMASPZAP,COND=(8,LT,ZAP)
//DD DD VOL=SER=&VS,UNIT=&DEV,DSN=&&DUMMY,SPACE=(6447,1)
//STEPLIB DD DSN=SYS1.ESPLIB,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSLIB DD VOL=SER=&VS,UNIT=&DEV,DISP=OLD,DSN=FORMAT4.DSCB
//SYSIN DD DSN=GERHARD.MVS.ESPPARM(F4ZAPOS),DISP=SHR

The ZAP texts are:
F4ZAPDOS:
CCHHR 0000000101 * VTOC ADDRESS
VER 2C F4 * REALLY DSCB 4 ?
VER 3A 06 * MVS VERSION OF DIRF ?
REP 3A 04 * YES; REPLACE BY SVS/MVT VERSION
*
CCHHR 0000000101 * VTOC ADDRESS
VER 2C F4 * REALLY DSCB 4 ?
VER 3A 02 * RECLAIM ONLY ?
REP 3A 04 * YES; SET FMT 5 BAD
*

F4ZAPOS:
CCHHR 0000000101 * TOC ADDRESS
VER 2C F4 * REALLY DSCB 4 ?
VER 3A 02 * RECLAIMED ?
REP 3A 00 * FIX IT
*

Gerhard Postpischil
Bradford, VT
Mike Stramba mikestramba@gmail.com [hercules-390]
2015-12-17 20:05:14 UTC
Permalink
The pack shouldn't be full.

It was freshly dasdload'd with just the one 225 byte text file.

MIK001 was an earlier pack.

TXT001 was the latest one I created.

I've used dasdload awhile ago without this "no space" problem.

I'll investigate further.

Mike
Post by Gerhard Postpischil ***@charter.net [hercules-390]
I've had poor success using IBM methods. I have a procedure and some
data to ZAP the format 4, allocate, and ZAP it again to reset the
contaminated/bit. But I don't recall ever running it against a
completely full pack. Perhaps changing the DD DD to TRK,0 may work.
//FIXPACK PROC VS=VOLSER,DEV='SYSALLDA'
//*
//* THIS IS A SYSTEMS PROCEDURE
//* ACCOUNT=Z904
//*
//* THIS PROCEDURE WILL ATTEMPT TO CLEAN UP SOME VTOC ERRORS WHICH
//* RESULT FROM SYSTEM CRASHES DURING A VTOC UPDATE. THE JOB WILL
//* FAIL ON A JCL ERROR IF THE VOLUME IS TOO FRAGMENTED TO PERMIT
//* CLEANUP. THIS JOB SHOULD BE RUN WHEN NO OTHER JOBS WILL ACCESS
//* THE SAME PACK. PLEASE CONSULT SYSTEMS IF THE PACK STILL IS BAD
//* AFTER THIS RUN.
//*
//*
//ZAP EXEC PGM=AMASPZAP
//STEPLIB DD DSN=SYS1.ESPLIB,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSLIB DD VOL=SER=&VS,UNIT=&DEV,DISP=OLD,DSN=FORMAT4.DSCB
//SYSIN DD DSN=GERHARD.MVS.ESPPARM(F4ZAPDOS),DISP=SHR
//*
//PAP EXEC PGM=AMASPZAP,COND=(8,LT,ZAP)
//DD DD VOL=SER=&VS,UNIT=&DEV,DSN=&&DUMMY,SPACE=(6447,1)
//STEPLIB DD DSN=SYS1.ESPLIB,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSLIB DD VOL=SER=&VS,UNIT=&DEV,DISP=OLD,DSN=FORMAT4.DSCB
//SYSIN DD DSN=GERHARD.MVS.ESPPARM(F4ZAPOS),DISP=SHR
CCHHR 0000000101 * VTOC ADDRESS
VER 2C F4 * REALLY DSCB 4 ?
VER 3A 06 * MVS VERSION OF DIRF ?
REP 3A 04 * YES; REPLACE BY SVS/MVT VERSION
*
CCHHR 0000000101 * VTOC ADDRESS
VER 2C F4 * REALLY DSCB 4 ?
VER 3A 02 * RECLAIM ONLY ?
REP 3A 04 * YES; SET FMT 5 BAD
*
CCHHR 0000000101 * TOC ADDRESS
VER 2C F4 * REALLY DSCB 4 ?
VER 3A 02 * RECLAIMED ?
REP 3A 00 * FIX IT
*
Gerhard Postpischil
Bradford, VT
somitcw@yahoo.com [hercules-390]
2015-12-17 20:21:01 UTC
Permalink
Post by Mike Stramba ***@gmail.com [hercules-390]
The pack shouldn't be full.
It was freshly dasdload'd with just the one 225 byte text file.
MIK001 was an earlier pack.
TXT001 was the latest one I created.
I've used dasdload awhile ago without this "no space" problem.
I'll investigate further.
Mike
There was a recent Hercules change for DASDLOAD setting on
the DIRF bit instead of the DOS contamination bit.
Perhaps the DASDLOAD changed missed the DIRF bit?

That is why I suggested printing the format 4 DSCB

After getting the proper documentation, a quick fix would be to
zap either bit on before allocating the temporary data set?
somitcw@yahoo.com [hercules-390]
2015-12-17 21:28:20 UTC
Permalink
In hercules-***@yahoogroups.com, <***@...> wrote:
- - - all snipped - - -

DS4VTOCI VTOC Indicators = X'2C' key + X'0E' data displacement = X'3A'

DS4DOSBT EQU X'80' DOS Contamination bit
DS4DIRF EQU X'04' DIRF bit

If either is set to one then MVS builds or rebuilds the free
space DSCBs on the next disk space change on that disk
volume. A console message indicates if the bit was DOS
or DIRF.

Both DASDLOAD and ICKSADSF leave one bit on instead
of trying to be an MVS type operating system and putting
proper free space extents in the VTOC.

DOS type of systems turn on the DOS contamination bit
when updating a disk VTOC that doesn't already have it on.
somitcw@yahoo.com [hercules-390]
2015-12-18 04:00:24 UTC
Permalink
In hercules-***@yahoogroups.com, <***@...> wrote:
- - - all snipped - - -

Perhaps someone else can recreate the issue.
My attempt to recreate it did not have the reported issue.

I installed Hercules 3.12 on Windows 10 Home that has current Windows updates.
The .msi closed Windows Explorer which of course closed the desktop.
With only a black screen, I used used cntl-alt-delete to open task manager,
under File, started a new task of explorer.exe to have a desktop again.
Then switched to the Hercules 3.12 .zip file for the install.

The test may have picked up Hercules 3.11 that I never installed,
but I don't know how:
C:\Program Files\Hercules.R3.12>dasdload
Hercules DASD loader program Version 3.11
(c)Copyright 1999-2010 by Roger Bowler, Jan Jaeger, and others

To try to recreate the issue, I ran dasdload that kept running to the end of
the control file and it claimed: "HHCDL020E Line too long in test.cntl line 3"
so never wrote the VTOC or updated the VOL1 label for the VTOC address.
To circumvent, added two lines to the end of the .cntl file.
One line of #CRLF and the other just a CRLF
Probably only need the "empty" line?

MIK001 3390 *
VTOC VTOC TRK 14
HERC02.TXT seq vstore.c TRK 10 10 0 PS FB 80 19040 0
#


On MVS 3.8j, ran the following:

//IEHLIST EXEC PGM=IEHLIST
//SYSPRINT DD SYSOUT=*
LISTVTOC VOL=3390=MIK001 statement starts in column 2
//VMIK001 DD UNIT=3390,VOL=SER=MIK001,DISP=SHR

THERE ARE 0000 EMPTY CYLINDERS PLUS 00000 EMPTY TRACKS ON THIS VOLUME
THERE ARE 00697 BLANK DSCBS IN THE VTOC ON THIS VOLUME

FORMAT 4 DSCB display list:
VI
80
Start of format 4 DSCB data in hex:
F4000000 010302B9 04590000 00008001
So DS4DOSBT, the DOS Contamination bit is on.


//IEFBR14 EXEC PGM=IEFBR14
//X DD UNIT=3390,VOL=SER=MIK001,SPACE=(TRK,0) even zero works
//

23.17.44 JOB 102 IEF403I HERC01I - STARTED - TIME=23.17.44
23.17.44 JOB 102 IEC604I VTOC CONVERT ROUTINE ENTERED ON 290,MIK001,DOS
23.17.44 JOB 102 IEFACTRT - Stepname Procstep Program Retcode
23.17.44 JOB 102 HERC01I IEFBR14 IEFBR14 RC= 0000
23.17.44 JOB 102 IEF404I HERC01I - ENDED - TIME=23.17.44

Another LISTVTOC shows:
THERE ARE 1112 EMPTY CYLINDERS PLUS 00005 EMPTY TRACKS ON THIS VOLUME
THERE ARE 00697 BLANK DSCBS IN THE VTOC ON THIS VOLUME
Mike Stramba mikestramba@gmail.com [hercules-390]
2015-12-18 12:12:24 UTC
Permalink
Post by ***@yahoo.com [hercules-390]
The test may have picked up Hercules 3.11 that I never installed,
Ya, thats's very strange. Though, if you fire up Hercules itself,
what is the reported version?
I'm gonna guess it's still 3.11, and you're "3.12 install" didn't ...
maybe ? ;)
Post by ***@yahoo.com [hercules-390]
C:\Program Files\Hercules.R3.12>dasdload
Hercules DASD loader program Version 3.11
When I use dasdload ver 3.11, all is well.

dasdload 3.12 seems to be broken.

That was also with *tk3 running under herc 3.12*.
somitcw@yahoo.com [hercules-390]
2015-12-18 17:22:08 UTC
Permalink
Post by ***@yahoo.com [hercules-390]
The test may have picked up Hercules 3.11 that I never installed,
Ya, thats's very strange. Though, if you fire up Hercules itself,
what is the reported version?
You just answered all of the questions.
DASDLOAD 3.12 is so broken that you need to zap the VTOC
of any disk created with it to get OS disk free space to work.
I'm gonna guess it's still 3.11, and you're "3.12 install" didn't ...
maybe ? ;)
Since the .msi file ended my desktop, I downloaded the .zip
as already posted. The problems were:

1. I had downloaded hercules-3.12.zip instead of hercules-3.12-w64.zip
I have now renamed hercules-3.12.zip to hercules-3.12.source.zip
and unzipped the correct file.
My Windows/DOS PATH was set to my Hercules 3.10 folder that
somehow had Hercules 3.11 in it. I'll delete my 3.10/3.11 mess.

2. The .cntl file still required the last line of it have CRLF stuck on
the end of it. Weird to end a file with a line terminator but I finally
figured out that was needed. I'm glad that it didn't pick some other
strange characters needed to end the last line.

3. The output VTOC indicators field is wrong.
Post by ***@yahoo.com [hercules-390]
C:\Program Files\Hercules.R3.12>dasdload
Hercules DASD loader program Version 3.11
When I use dasdload ver 3.11, all is well.
dasdload 3.12 seems to be broken.
That was also with *tk3 running under herc 3.12*.
You initially claimed, "Tested with Herc 3.12, 3.11"
so I didn't worry about the version showing 3.11 but
just noted it.

Retested and found that DASDLOAD 3.12 is broken.
It set the format 4 dscb VTOC indicators to X'40'
which isn't defined for MVS 3.8j.
I assUme that someone was trying to change X'80'
to X'04' but suffers from dyslexia?

The bad VTOC indicator was why MVS did not know
to build the free space DSCBs.

P.S. If you had posted the documentation asked for,
either the LISTVTOC or a zap DUMP, the cause of
this issue would have been known several posts back.

somitcw@yahoo.com [hercules-390]
2015-12-17 16:43:14 UTC
Permalink
In hercules-***@yahoogroups.com, <***@...> wrote:
- - - most snipped - - -
HERC02.ABC01.TXT seq ABC.txt TRK 10 10 0 PS F 80 19040
How can RECFM=F ( that is fixed unblocked ) have a
BLKSIZE other than the LRECL ?

It should be either RECFM=FB or it should be BLKSIZE=80

Unblocked is high unbelievable overhead so should be avoided.
Mike Stramba mikestramba@gmail.com [hercules-390]
2015-12-17 17:05:21 UTC
Permalink
Good catch, thanks. It's working now with FB.
Post by ***@yahoo.com [hercules-390]
- - - most snipped - - -
HERC02.ABC01.TXT seq ABC.txt TRK 10 10 0 PS F 80 19040
How can RECFM=F ( that is fixed unblocked ) have a
BLKSIZE other than the LRECL ?
It should be either RECFM=FB or it should be BLKSIZE=80
Unblocked is high unbelievable overhead so should be avoided.
Loading...