On Wed, 23 May 2018 17:41:43 +0000, Jesse 1 Robinson wrote:
>Sorry for a war story on Wednesday, but it's too good to suppress. We
>implemented the ICEGENER strategy at a former shop in the 80s. What could go
>wrong? Seems that some (of course critical) application was creating a
>sequential file in which the actual number of blocks was calculated. File was
>created on DASD and IEBGENERed to tape. The JCL that created the tape file did
>not code BLKSIZE; just depended on IEBGENER's habit of copying input DCB to
>output. You've all seen the warning message.
>
>File was later read in by another program that expected the original number of
>blocks. But ICEGENER had already stepped in to help out by reblocking the file
>to SDB. Good for tape usage; fatal for the program that expected a set number
>of blocks. 30 years later I still shake my head over that one.
>
IIRC, IEBGENER proper went through similar gyrations at the inception of SDB.
It first switched from copying DCB to relying on SDB, then introduced a PARM
option to select the old benavior, and still later made the classical behavior
the
default.
I just RTFM. It has become dreadfully complicated. It depends on
PARM={INPUT|YES|SMALL|LARGE|NO}. (Is PARM='' supported?
(The doc doesn't say that.) And on the setting of COPYSDB in
SYS1.PARMLIB.COPYSDB(DEVSUPxx). And on SMS options. It
doesn't make it clear in view of all this newfangled stuff what the
individual applications programmer can do to guarantee replicating
BLKSIZE from SYSUT1 to SYSUT2.
Hiwever, I dislike any design that depends on blocking factors. A
better design of your program would have been to depend on a
particular number of records rather than a particular number of
blocks. Think QSAM, not BSAM.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
