Re: 3380-3390 Conversion - DISAPPOINTMENT

[willie bunter]

Hi,
   
  I was the originator of the post and I asked for help.  Somewhere down the 
line the thread got hi-jacked and the discussion became one about contractors 
and the antagonism towards them.  I am very disappointed at the lack of 
professionalism.  
   
  Again, if someone out there has any tips or information regarding 3380-3390 
conversion please, please answer back.
   
  I apologise for my diatribe but I am desperate for help and information.


-
New Yahoo! Messenger with Voice. Call regular phones from your PC for low, low 
rates.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Mike Bell]

VSAM is VSAM - so DB2 and IMS that is on VSAM can be moved with DF/DSS or
any other tool. someone already said that.
IMS that is on OSAM is not device dependent but the blksize was probably
chosen for 3380 optimum - The DBA's will have to fix it later. If you mark
the old volumes as disabled for new allocations, HSM migrate and recall will
move to the new packs. I have done it both ways.  I would recomend taking
your biggest files and moveing them with DF/DSS.  SMS will scatter the new
allocations accross all the packs so it doesn't really matter how you do
it.
DB2 image copies, archive logs, IMS image copies and logs are all QSAM and
idenpendent of device. blksizes may not be optimum but I doubt it is worth
changing.

The single biggest issue I remember was blksize on loadlibs. After much
discussion, we moved them manually with copymod to set new blksizes.

Mike


On 3/23/06, willie bunter <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
>   I was the originator of the post and I asked for help.  Somewhere down
> the line the thread got hi-jacked and the discussion became one about
> contractors and the antagonism towards them.  I am very disappointed at the
> lack of professionalism.
>
>   Again, if someone out there has any tips or information regarding
> 3380-3390 conversion please, please answer back.
>
>   I apologise for my diatribe but I am desperate for help and information.
>
>
> -
> New Yahoo! Messenger with Voice. Call regular phones from your PC for low,
> low rates.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>



--
Mike

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[willie bunter]

Thanks Mike for the info.  We have FDR.  I presume it should work just the same.
   
  Thanks for answering my SOS.

Mike Bell <[EMAIL PROTECTED]> wrote:
  VSAM is VSAM - so DB2 and IMS that is on VSAM can be moved with DF/DSS or
any other tool. someone already said that.
IMS that is on OSAM is not device dependent but the blksize was probably
chosen for 3380 optimum - The DBA's will have to fix it later. If you mark
the old volumes as disabled for new allocations, HSM migrate and recall will
move to the new packs. I have done it both ways. I would recomend taking
your biggest files and moveing them with DF/DSS. SMS will scatter the new
allocations accross all the packs so it doesn't really matter how you do
it.
DB2 image copies, archive logs, IMS image copies and logs are all QSAM and
idenpendent of device. blksizes may not be optimum but I doubt it is worth
changing.

The single biggest issue I remember was blksize on loadlibs. After much
discussion, we moved them manually with copymod to set new blksizes.

Mike


On 3/23/06, willie bunter wrote:
>
> Hi,
>
> I was the originator of the post and I asked for help. Somewhere down
> the line the thread got hi-jacked and the discussion became one about
> contractors and the antagonism towards them. I am very disappointed at the
> lack of professionalism.
>
> Again, if someone out there has any tips or information regarding
> 3380-3390 conversion please, please answer back.
>
> I apologise for my diatribe but I am desperate for help and information.
>
>
> -
> New Yahoo! Messenger with Voice. Call regular phones from your PC for low,
> low rates.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>



--
Mike

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html



-
New Yahoo! Messenger with Voice. Call regular phones from your PC for low, low 
rates.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Stephen Mednick]

Willie,

As you've said that you have FDR, take a look at Section 80.12 titled "Data
Movement Between Different Device Devices".


Stephen Mednick
Computer Supervisory Services
Sydney, Australia

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of willie bunter
> Sent: Friday, 24 March 2006 12:35 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: 3380-3390 Conversion - DISAPPOINTMENT
> 
> Thanks Mike for the info.  We have FDR.  I presume it should 
> work just the same.
>
>   Thanks for answering my SOS.
> 
> Mike Bell <[EMAIL PROTECTED]> wrote:
>   VSAM is VSAM - so DB2 and IMS that is on VSAM can be moved 
> with DF/DSS or any other tool. someone already said that.
> IMS that is on OSAM is not device dependent but the blksize 
> was probably chosen for 3380 optimum - The DBA's will have to 
> fix it later. If you mark the old volumes as disabled for new 
> allocations, HSM migrate and recall will move to the new 
> packs. I have done it both ways. I would recomend taking your 
> biggest files and moveing them with DF/DSS. SMS will scatter 
> the new allocations accross all the packs so it doesn't 
> really matter how you do it.
> DB2 image copies, archive logs, IMS image copies and logs are 
> all QSAM and idenpendent of device. blksizes may not be 
> optimum but I doubt it is worth changing.
> 
> The single biggest issue I remember was blksize on loadlibs. 
> After much discussion, we moved them manually with copymod to 
> set new blksizes.
> 
> Mike
> 
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Stephen Mednick]

Whoops, that should have been:

"Data Movement Between Different DASD Devices"

Stephen Mednick
Marketing & Support Manager
Computer Supervisory Services
Tel: +61 (2) 9665 1104
Fax: +61 (2) 9665 7382



> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Mednick
> Sent: Friday, 24 March 2006 12:55 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: 3380-3390 Conversion - DISAPPOINTMENT
> 
> Willie,
> 
> As you've said that you have FDR, take a look at Section 
> 80.12 titled "Data Movement Between Different Device Devices".
> 
> 
> Stephen Mednick
> Computer Supervisory Services
> Sydney, Australia
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Mike Bell
> 
> [ snip ]
> 
> The single biggest issue I remember was blksize on loadlibs. 
> After much discussion, we moved them manually with copymod to 
> set new blksizes.

IBM has been recommending BLKSIZE=32760 for load libraries for at least
a decade.

-jc-

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[John Eells]

Chase, John wrote:

-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Mike Bell

[ snip ]

The single biggest issue I remember was blksize on loadlibs. 
After much discussion, we moved them manually with copymod to 
set new blksizes.



IBM has been recommending BLKSIZE=32760 for load libraries for at least
a decade.



Absolutely true for system software load libraries.  I don't 
recall that we ever recommended a specific block size for other 
load libraries, except perhaps by thoughtlessly omitting the "for 
system software target libraries" phrase in an informal setting 
(say, here in IBM-MAIN).


For example, using 32760 for other load libraries can cause some 
head-scratching and extra work during device conversions...which, 
oddly enough, is the current topic!  That's one reason we never 
recommended it in the general case.


Another is that system software target libraries tend to be built 
on the device types from which they will be used, and tended by 
sysprogs who might remember to reblock them during a conversion 
effort.  Application libraries, by contrast, might bounce around 
among different device geometries under DFSMShsm control or be 
moved by storage administrators who are moving *so* much stuff at 
once that fine-tuning isn't a reasonable option.  For these 
libraries, a reasonable submultiple of the track lengths of the 
different devices--that is, one that yields reasonable space 
utilization on each one--might well be better choice of block 
size.  (Ever wonder where all those 6K-ish block sizes came from? 
 Now you know.)


In any case, for block sizes that are not reasonable submultiples 
of the two track lengths in question, you should always move load 
libraries between different device types using IEBCOPY COPYMOD, 
*not* COPY.  Otherwise, particularly for data sets with large 
block sizes, the difference in track lengths will result in truly 
abysmal space utilization for those data sets having load modules 
with lots of long text blocks and less-than-optimum space 
utilization for most of the rest.


Also, to avoid RC4s from COPYMOD that would make a duly diligent 
sysprog from looking at (and up) messages that don't matter, 
always use PARM=SPCLCMOD with COPYMOD.


John Eells
z/OS Technical Marketing
IBM Poughkeepsie

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Ed Finnell]

 
In a message dated 3/24/2006 6:56:41 A.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

IBM has  been recommending BLKSIZE=32760 for load libraries for at least
a  decade.



>>
Sell that DASD?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Mike Bell]

Yes, but this conversion happended about 20 years ago.  Some of the loadlibs
were still blocked for 3330.  Others were blocked to numbers that made no
sense at all.  production control had a lot of code to handle the different
blksizes but still had periodic problems (one or two a year). . It was a
chance to clean up a long standing mess.

Mike

On 3/24/06, Chase, John <[EMAIL PROTECTED]> wrote:
>
> > -Original Message-
> > From: IBM Mainframe Discussion List On Behalf Of Mike Bell
> >
> > [ snip ]
> >
> > The single biggest issue I remember was blksize on loadlibs.
> > After much discussion, we moved them manually with copymod to
> > set new blksizes.
>
> IBM has been recommending BLKSIZE=32760 for load libraries for at least
> a decade.
>
> -jc-
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>



--
Mike

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Eric Bielefeld]

When we converted 10 to 15 years ago, I just used FDR/DSF and DFDSS to 
copy data.  You have to do the dataset copy, not the full volume dump 
copy.  I also changed the naming convention of the volsers.  I think it 
was something like PRD0nn to PRD3nn - the PRD0nn being the original 
3380K drives, the PRD3nn being 3390 Mod 3 drives.  I copied much of the 
data during first shift, making sure that it was not in use.  Most of 
the VSAM and IMS files which were always in use by CICS during the day 
were converted by doing the application backups and doing restores on 
the weekend.  

Eric Bielefeld
Sr. Systems Programmer
P&H Mining Equipment
414-671-7849
Milwaukee, Wisconsin


- Original Message -
From: willie bunter <[EMAIL PROTECTED]>
Date: Thursday, March 23, 2006 7:13 pm
Subject: Re: 3380-3390 Conversion - DISAPPOINTMENT
To: IBM-MAIN@BAMA.UA.EDU

> Hi,
>   
>  I was the originator of the post and I asked for help.  
> Somewhere down the line the thread got hi-jacked and the 
> discussion became one about contractors and the antagonism towards 
> them.  I am very disappointed at the lack of professionalism.  
>   
>  Again, if someone out there has any tips or information 
> regarding 3380-3390 conversion please, please answer back.
>   
>  I apologise for my diatribe but I am desperate for help and 
> information.
>   

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Ron and Jenny Hawkins]

Ed,

I don't understand your comment.

COPYMOD has always adjusted the size of text blocks to optimally fill the
track, so in actual fact 32760 for load libraries will sell less DASD, not
more.

Ron

> >>
> Sell that DASD?
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[willie bunter]

Hi Eric,
   
  Thanks for getting back to me.  If you do have any info lying around I would 
be very happy to accept it.  You mention IMS files.  Did you use the vendor 
supplied utilities to transfer them?  I remember in 1993 I had a problem with 
IMS.  I used DFDSS to copy and restore (selective).  The job ran fine, but when 
I brought up CICS encountered abends.  Being under the gun, I performed a 
restore using the IMS utility.
   
  Was your system SMS managed? If not how did you handle the jcls having hard 
coded volsers?
   
  Also of great interest to me is how you moved the catalogs.  Can you jog your 
memory and let me know how you went about it?  Did you use a special sequence 
to do it, for example did you move the UCAT, then MCAT and last of all System 
Catalaog?
   
  I have posed quite a few questions and I implore your patience.
   
  Thanks

Eric Bielefeld <[EMAIL PROTECTED]> wrote:
  When we converted 10 to 15 years ago, I just used FDR/DSF and DFDSS to 
copy data. You have to do the dataset copy, not the full volume dump 
copy. I also changed the naming convention of the volsers. I think it 
was something like PRD0nn to PRD3nn - the PRD0nn being the original 
3380K drives, the PRD3nn being 3390 Mod 3 drives. I copied much of the 
data during first shift, making sure that it was not in use. Most of 
the VSAM and IMS files which were always in use by CICS during the day 
were converted by doing the application backups and doing restores on 
the weekend. 

Eric Bielefeld
Sr. Systems Programmer
P&H Mining Equipment
414-671-7849
Milwaukee, Wisconsin


- Original Message -
From: willie bunter 
Date: Thursday, March 23, 2006 7:13 pm
Subject: Re: 3380-3390 Conversion - DISAPPOINTMENT
To: IBM-MAIN@BAMA.UA.EDU

> Hi,
> 
> I was the originator of the post and I asked for help. 
> Somewhere down the line the thread got hi-jacked and the 
> discussion became one about contractors and the antagonism towards 
> them. I am very disappointed at the lack of professionalism. 
> 
> Again, if someone out there has any tips or information 
> regarding 3380-3390 conversion please, please answer back.
> 
> I apologise for my diatribe but I am desperate for help and 
> information.
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html



-
New Yahoo! Messenger with Voice. Call regular phones from your PC for low, low 
rates.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Gerhard Adam]

I don't understand your comment.

COPYMOD has always adjusted the size of text blocks to optimally fill the
track, so in actual fact 32760 for load libraries will sell less DASD, not
more.



I don't understand the issue.  Load libraries have an undefined record 
format precisely because the majority of the records are significantly less 
than the block size.  In fact, the only thing that would ever be blocked to 
the maximum value would be the TXT records for a module.  Since a load 
module consists of other records besides TXT (which are all less than 256 
bytes in length), the traditional concept of a block size is practically 
meaningless when applied to load libraries.


Single CSECT load modules are almost never large enough to use the maximum 
(32760) since that would require 8 base registers, so the only load modules 
that would produce TXT large enough to take advantage of the maximum block 
size are those that consist of multiple bound modules.  Even then, the 
"benefit" would only come from a minimal savings on disk and a possible 
savings in fewer I/O's to load the module.  Since both of these are 
extremely difficult to quantify in the case of load libraries, it becomes 
largely academic what values are chosen.  IMHO I don't see a difference 
between 32760 and 6144, since the majority of the records are actually < 256 
bytes.


Adam 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[(IBM Mainframe Discussion List)]

 
 
In a message dated 3/24/2006 1:29:56 P.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

>Single CSECT load modules are almost never large enough to use the  maximum 
>(32760) since that would require 8 base registers, so the only  load modules 
>that would produce TXT large enough to take advantage of  the maximum block 
>size are those that consist of multiple bound  modules.
There are many ways to produce a single CSECT of only one module that  uses 
only one base register at any one time.


Bill  Fairchild


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Gerhard Adam]

>There are many ways to produce a single CSECT of only one module that
uses 
>only one base register at any one time.


It begs the question, since the issue isn't whether it can be done, but
whether it would be considered a typical size for a load module.

Adam

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Patrick O'Keefe]

On Fri, 24 Mar 2006 09:23:12 -0500, John Eells <[EMAIL PROTECTED]> wrote:

>...
>> IBM has been recommending BLKSIZE=32760 for load libraries for at least
>> a decade.
>
>
>Absolutely true for system software load libraries.  ...

Yes, but    While IBM has been preaching 32760 for loadlibs and system-
determined blocksizes for other libraries, it has also been churning out
some Program Directories that have not been rewritten for decades, with
BLKSIZE=6144 for loadlibs, 3200 for LRECL=80 datasets, etc.  And some
people are afraid to go against Program Directories, even when the info
is against the latest recommendations elsewhere; even when the info is
obviously obsolete.

Maybe I've been unlucky enough to work with the last few products to
update their program directories.  (But I doubt it.)

Pat O'Keefe

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Gerhard Adam]

>Yes, but    While IBM has been preaching 32760 for loadlibs and
system-
>determined blocksizes for other libraries, it has also been churning
out some Program Directories that have not been rewritten for decades,
with BLKSIZE=
>6144 for loadlibs, 3200 for LRECL=80 datasets, etc.  And some people
are afraid to go against Program Directories, even when the info is
against the 
>latest recommendations elsewhere; even when the info is obviously
obsolete.

Why should this be considered obsolete?  Why does anyone really care?
What is the supposed benefit of 32760 over 6144?

Adam

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Eric Bielefeld]

Willie,

I'll try to answer all of your questions. I'll do this one from the
listserve web site, as it doesn't time out like my Roadrunner Email account
does when I take a little too long to reply.  I found some of my old JCL,
so I'll cut and paste that for the catalog moves.

1.  I think all of the IMS files were moved using the application backup
software.  I think we use a product from BMC that does faster backups and
restores.  We changed all of the delete defines for all of the master
files, and the next time they were reorged, they would go to the 3390
volume.

2.  We have almost no SMS managed data.  As in 1 above, we changed the
delete defines, which then had the new volser hard coded.

3.  I don't remember how I moved the MCAT, but I think I built a new one,
and then just changed the catalog pointer in the LOAD00 member to point to
the new catalog.  We have very little volatility in our MCAT.

4.  The user catalogs were all done on the weekend just before or after the
IPL.  Here are 4 jobs I ran to move a single catalog.  I kept the name of
each UCAT the same, as that seemed simpler.  Here are the jobs:

//TSYS2001 JOB (6377,TSO,),'MOVE LIB CAT 1',
// NOTIFY=TSYS200,
// CLASS=4,MSGCLASS=X,MSGLEVEL=(1,1)
//**
//*  MOVE LIB CAT JOB 1
//**
//MOVECAT  EXEC PGM=IDCAMS
//EXPDDDD  DSN=TSYS200.EXPORT.VLIB001,DISP=(NEW,CATLG),UNIT=TSO,
// SPACE=(CYL,(15,5),RLSE)
//SYSPRINT DD  SYSOUT=*
//SYSINDD  *
  EXPORT SYS1.USERCAT.VLIB001  OUTFILE(EXPDD) TEMPORARY
/*
//TSYS2002 JOB (6377,TSO,),'MOVE LIB CAT 2',
// NOTIFY=TSYS200,
// CLASS=4,MSGCLASS=X,MSGLEVEL=(1,1)
//**
//*  MOVE LIB CAT JOB 2
//**
//MOVECAT  EXEC PGM=IDCAMS
//SYSPRINT DD  SYSOUT=*
//SYSINDD  *
  DELETE SYS1.USERCAT.VLIB001  RECOVERY USERCATALOG
/*
//TSYS2003 JOB (6377,TSO,),'LIBCAT DEFINE JOB 3 ',MSGCLASS=X,
// CLASS=2,NOTIFY=TSYS200
//*
//* LIB: IPO1.JCLLIB(ICFUCAT)
//* GDE: CBIPO MVS CUSTOMIZATION
//* DOC: DEFINE AN ICF USER CATALOG
//*
//DEFINE1 EXEC PGM=IDCAMS
//SYSPRINT DD  SYSOUT=*
//VOL  DD  UNIT=3390,VOL=SER=LIB901,DISP=OLD
//SYSINDD  *
  DEFINE  USERCATALOG -
  (NAME(SYS1.USERCAT.VLIB001)   -
  CYLINDERS(20 5) -
  VOLUME(LIB901) -
  CONTROLINTERVALSIZE(4096)  -
  BUFND(4) -
  BUFNI(4) -
  STRNO(3) -
  NOIMBED -
  NOREPLICATE -
  FREESPACE(20 20) -
  RECORDSIZE(4086 32400) -
  ICFCATALOG  -
  FILE(VOL)) -
   CATALOG(SYS1.MCAT.VHSPCAT)
/*
//TSYS2004 JOB (6377,TSO,),'MOVE LIBCAT JOB 4',
// NOTIFY=TSYS200,
// CLASS=4,MSGCLASS=X,MSGLEVEL=(1,1)
//**
//*  MOVE CAT JOB 4
//**
//MOVECAT  EXEC PGM=IDCAMS
//EXPDDDD  DSN=TSYS200.EXPORT.VLIB001,DISP=OLD
//SYSPRINT DD  SYSOUT=*
//SYSINDD  *
  IMPORT INFILE(EXPDD) -
OUTDATASET(SYS1.USERCAT.VLIB001)   -
ALIAS UNLOCK INTOEMPTY
/*

I hope that helps.

Eric Bielefeld
P&H Mining Equipment


On Fri, 24 Mar 2006 10:29:20 -0800, willie bunter <[EMAIL PROTECTED]>
wrote:

>Hi Eric,
>
>  Thanks for getting back to me.  If you do have any info lying around I
would be very happy to accept it.  You mention IMS files.  Did you use the
vendor supplied utilities to transfer them?  I remember in 1993 I had a
problem with IMS.  I used DFDSS to copy and restore (selective).  The job
ran fine, but when I brought up CICS encountered abends.  Being under the
gun, I performed a restore using the IMS utility.
>
>  Was your system SMS managed? If not how did you handle the jcls having
hard coded volsers?
> sequence to do it, for example did you move the UCAT, then MCAT and last
of all System Catalaog?
>
>  I have posed quite a few questions and I implore your patience.
>
>  Thanks

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Ed Gould]

On Mar 24, 2006, at 8:23 AM, John Eells wrote:




SNIP---
Also, to avoid RC4s from COPYMOD that would make a duly diligent  
sysprog from looking at (and up) messages that don't matter, always  
use PARM=SPCLCMOD with COPYMOD.



John,

Had not heard about that parm before. I looked it up and it was as  
clear as mud... (ok dark bear).


I got the gist of it and I guess that is all that is important.

Maybe the DFSMS people could use the help of some people can speak  
plain English.


Ed

To get back to the main thread, except for SAS and IDMS databases  
(and IDCAMS for the catalogs) I used DFDSS. The catalog issue was  
chiefly  the issue of I wanted to do it because of well political  
reasons (enough said on that). I created a new mastercat and ran the  
"old" catalog with the program from the IPO tape that reads it and  
creates IDCAMS define statements to be run through idcams. I did use  
a stepcat so that could be an issue. (Don't get me going on stepcats)


The whole process went reasonably smoothly. I was on (at that time)  
bleeding edge apars with DFDSS (no blood on me though). When all was  
said and done it went well.


Of course the manual effort up front was not small, calling all the  
vendors etc. Its been over 15 years (IIRC) and all the vendors have  
incorporated all the fixes by now.


Ed

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Steve Arnett]

Ed Gould wrote:


On M
John,

Had not heard about that parm before. I looked it up and it was as  
clear as mud... (ok dark bear).




It is obviously Friday!  How much clearer is a light bear?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Ted MacNEIL]

>except for SAS

SAS went to strictly PS files with V6 (I think) and relative record/block 
access.
The issue from BDAM files disappeared in the conversion from 3380 to 3390, 
except for space.

Then they dropped support for BDAM in V8.

-
-teD

I’m an enthusiastic proselytiser of the universal panacea I believe in!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Ed Gould]

On Mar 24, 2006, at 12:00 AM, Ted MacNEIL wrote:


except for SAS


SAS went to strictly PS files with V6 (I think) and relative record/ 
block access.
The issue from BDAM files disappeared in the conversion from 3380  
to 3390, except for space.


Then they dropped support for BDAM in V8.

-
-teD


Ted,

Thanks... Of course this happened a long time ago before SAS converted.

Ed

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Ed Gould]

On Mar 24, 2006, at 3:57 PM, Steve Arnett wrote:


Ed Gould wrote:


On M
John,

Had not heard about that parm before. I looked it up and it was  
as  clear as mud... (ok dark bear).




It is obviously Friday!  How much clearer is a light bear?


Enough to see a face on the other side of the mug:)

Ed



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[John Eells]

** Very long post warning *

I thought I'd posted this before, but didn't see it in the 
archives.  This was originally written as a post to IBM's 
internal software packaging forum on the topic of block sizes to 
recommend for different system software data sets.


It's a bit dated now (written when SLED was the order of the day 
and RAID was new) but I think most of it still applies.  One 
thing it doesn't include that I should have mentioned back then 
is the overhead of simply needing more CCWs to get the job done; 
this still applies even though some of the physical delays no 
longer do.  But time to think about those updates and make them 
below is gone for this week, so...here 'tis, as it is.


Also, thanks to Darren for his help in allowing this extremely 
long post.


  What's a Block, Anyway?

When doing I/O to a tape or DASD device, LRECL is irrelevant. 
Only the block size matters.  This is because each physical 
record on tape and DASD is what we in software call a block. 
(This leads to interesting conversations sometimes between 
hardware and software people.  "You gave me a block."  "Nope, 
just one record.")  So when we write to one of these devices, we 
only care about the characteristics of a block.


There are three kinds of blocks: Fixed, Variable, and Undefined. 
 When a fixed block is written, the physical record is always 
equal to the block size except when there aren't enough records 
to fill an entire block.  In this case, the last block can be a 
short block.  Variable blocks are written on a block-by-block 
basis, and each block can be a different length.


The length of each variable block is stored in the physical 
record as the BDW, or Block Descriptor Word, and when there are 
variable-length records, there's a corresponding RDW, or...you 
guessed it...Record Descriptor Word.  The BDW's length is left as 
an exercise for the Alert Reader.  (Want a hint?  The maximum 
block length for data is 32760 in MVS, not 32768.  The actual 
maximum length of a block itself is 32768, and is limited by (at 
least) the specification of the block size in DEB as a signed 
two-byte field.  The hardware limit is established by the Count 
fields in both Format 0 and Format 1 CCWs, and is 64K.)


  Space and Block Length for FB

When fixed blocks are written to DASD, they start on a new track 
or continue on a partly-used track only when there is enough 
space left on the track to write the entire block.  This means 
that allocating FB data sets with block sizes above half the 
track length is a guaranteed way to waste lots of space.  Every 
time two full-size blocks follow one another, the balance of the 
track will be unused and the second full-size block written on 
the next track.


  Space and Block Length for VB

The above is entirely true for FB, but it's a slight 
simplification for VB.  For VB, the actual average block length 
will dictate whether space utilization gets worse as the block 
size rises.  This will be a function of the size of the members 
and the distribution of differently-sized members within each 
data set.  Since every new PDS member starts a new block, if all 
the members are small a high block size won't actually hurt 
anything.  But if some or all the members are larger than 1/2 
track, space utilization will get worse when the block size goes 
over half a track.


 Little Blocks are Bad

On the other hand, short block sizes are bad because space is 
wasted in between each record for Count and Key fields on CKD 
(Count, Key, and Data physical record formats) DASD, which is 
what we use in MVS.  To avoid wasting space between the records, 
we want to use high block sizes.


  Bigger Blocks are Better...to a Point

A reasonable compromise (for FB and VB) between too-short blocks 
and too-long blocks is half the track length, which minimizes the 
wastage on average.  It's actually a bit more complicated than 
that (pick up a DASD hardware book and a calculator for the gory 
details), but DFSMSdfp's System Determined Blocksize, or SDB, 
takes care of the complication and picks that value nearest half 
a track that's right for the device and the block size specified. 
 More or less, anyway.


For most data sets, this comes very close to optimizing space 
usage and performance.  Not perfect for every data set, mind you, 
but darn close for the overwhelming majority, and close enough 
that trying to write code to figure out *all* the intricacies 
would probably occupy someone in SVL for a lifetime (or two) and 
is probably light-years from cost-justified.  (For some reason, 
those pesky programmers want to get *paid*.  Sheesh!)


   Distribution of Member Sizes and Loading Order

However, the mix of block sizes and the order the members are 
loaded in can make SDB less-than-optimum for some data sets. 
(Remember, too, that each PDS 

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Ron and Jenny Hawkins]

Gerhard,

The Text records may be 256 bytes, but they are blocked, and the Blocksize
of the "text" block will be up to the blksize of the loadlib.

Two verifications:
1) Browse any medium size load module in you load libraries and page right.
Browse reads the modules as a recfm=u file, and you will see text block
characters continue well past byte 256.

2) There was a fix for IEBCOPY years ago where "FAT RECORSS" were causing a
problem. FAT records were caused where modules were created with text blocks
larger than the Loadlib blksize. This couldn't happen if text records were
not blocked.

Ron

> 
> I don't understand the issue.  Load libraries have an undefined record
> format precisely because the majority of the records are significantly
> less
> than the block size.  In fact, the only thing that would ever be blocked
> to
> the maximum value would be the TXT records for a module.  Since a load
> module consists of other records besides TXT (which are all less than 256
> bytes in length), the traditional concept of a block size is practically
> meaningless when applied to load libraries.
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Gerhard Adam]

>The Text records may be 256 bytes, but they are blocked, and the
Blocksize of the "text" block will be up to the blksize of the loadlib.

>Two verifications:
>1) Browse any medium size load module in you load libraries and page
right. Browse reads the modules as a recfm=u file, and you will see text
block 
>characters continue well past byte 256.

>2) There was a fix for IEBCOPY years ago where "FAT RECORSS" were
causing a problem. FAT records were caused where modules were created
with text blocks 
>larger than the Loadlib blksize. This couldn't happen if text records
were not blocked.

I agree and I believe I stated as much when I said that the only element
in a load library that could take advantage of the blocksize was the TXT
records.  However, my issue is that the significant number of ESD, RLD,
etc records which are NOT blocked and therefore will continue to "waste"
space on DASD regardless of the overall blocksize.  In addition, since
most load module CSECTS are NOT 32K in size, they would also be written
as short blocks.  As a consequence, my point is that all this discussion
about optimum blocksizes for load libraries seems a bit over-stated.

Thanks for your response

Adam

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Bruce Black]

John, what a great post!  thorough, well-organized, mostly easy to 
understand.  You should consider getting a version added to the Using 
Data Sets manual, or at least published as a TechNote.


A point you might want to add:

For PDSs there is an additional track utilization issue and that is the 
EOF record written at the end of every member.  EOFs are the smallest 
possible record (0 bytes in length) but that have the overhead of a real 
record and take up space on the track all out of proportion to their 
size.  Even if a PDS uses half-track blocking and every block is a full 
block, it will still waste space on each track because of the EOF, 
leaving no room for a second block



--
Bruce Black
Senior Software Developer
Innovation Data Processing

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Ron and Jenny Hawkins]

Adam,

Yes there are a few RLD, ESC, etc records and they are LE 256 bytes. However
this does not affect the blocking of the text blocks. 

If, after writing a few small records a track has space remaining for a text
block up to the Max block size then it will use the max block size.

If the remaining space will fit a text block less than the Max block size,
but greater than the Min block size then it will write a short block in
order to fill the track.

Using this sort of smart blocking COPYMOD does not leave any unnecessary
empty space on the track.

Looking at a few random samples of modules in SYS1.LINKLIB (only 5), my
observation is that while there are only a few text blocks, they are usually
around 90% of the size of the module.

There have been numerous recommendations over the last 20 years to reblock
load libraries with SAS PROC PDSCOPY, and then later IEBCOPY with COPYMOD.
For me empirical evidence counts a lot. Choose a few of your well loved
loadlibs that have a 6KB blocksize and make a copy with COPYMOD using 32760
BLKSIZE. I'll bet The Sydney Harbour Bridge to a dollar that they the used
space is less than the source loadlib.

Ron

> 
> I agree and I believe I stated as much when I said that the only element
> in a load library that could take advantage of the blocksize was the TXT
> records.  However, my issue is that the significant number of ESD, RLD,
> etc records which are NOT blocked and therefore will continue to "waste"
> space on DASD regardless of the overall blocksize.  In addition, since
> most load module CSECTS are NOT 32K in size, they would also be written
> as short blocks.  As a consequence, my point is that all this discussion
> about optimum blocksizes for load libraries seems a bit over-stated.
> 
> Thanks for your response
> 
> Adam
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Gerhard Adam]

Ron:

You are correct that the library will typically use less space,
however ... This is very much dependent on the size of the CSECTS within
it.  I don't have a problem with the assertion that 32760 results in
larger TXT blocks being written, but unless you have a library that has
such large blocks, it is not a foregone conclusion that you'll save
anything.

In doing a couple of experiments, SYS1.LINKLIB resulted in the
following:

Blocked from 6144 to 32760 - 13% savings
Blocked from 6144 to 23476 - 11% savings
Blocked from 6144 to 13030 - 9% savings

Interestingly enough when COPYMOD was used to reblock it to 6144 from
6144 there was a net savings of 2%. (In all cases, the library was
copied fresh, so there was no need for compression to remove "dead"
space.)

We can surmise from these savings that we are primarily dependent on the
average size of the TXT records in the load module.  The largest
incremental savings occurred when blocking doubled to 13030, so the
primary benefit occurred for CSECTS that were between 8 - 12K in size.
When we increased the blocksize again, we picked up those few CSECTS
that were larger, and so on. 

SYS1.LPALIB gained a savings of 33% from the reblocking (6144 to
32760).

CAILIB only gained about 8% savings.

But, as I stated earlier, these libraries probably contain the
largest load modules and consequently might benefit to varying degrees
by re-blocking.  However, based on the observed 2% savings using
COPYMOD, I do wonder how much of the "savings" would have been lost
through normal use of the Binder.  

Let me re-iterate.  I don't dispute the fact that the larger
blocksizes will result in larger TXT records being written which can
result in space savings.  I guess what I'm trying to say is that I don't
find it that exciting to save 2% or 4% in a dataset.

I'm also suggesting that despite the 32760 blocksize
recommendations, perhaps it simply isn't worth the effort in most cases
to worry about changing how libraries are distributed.  (I know I
certainly wouldn't lead a crusade to reblock all my installation load
libraries).

Anyway ... Thanks for your comments.

Adam

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[(IBM Mainframe Discussion List)]

 
 
In a message dated 3/24/2006 7:13:27 P.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

Excellent basic primer on records and blocks.  A few comments for  the more 
advanced user:
 
>each physical record on tape and DASD ...
>...
>The hardware limit is established by the Count fields in both  Format 0 and 
Format 1 >CCWs, and is 64K.)
The maximum number of bytes that can be transferred by one CCW is  65,535.  
But you can have any number of CCWs, each transferring 65,535  bytes and using 
data chaining, to make a much larger block than 64K.  Of  course, such a block 
cannot be handled by standard access methods.  On  tape there is no limit.  
On DASD the limit these days is one full track,  but on DASDs prior to the 3380 
there was a feature called Write Special CKD  that would let you write a 
single DASD hardware record (aka a software block)  that was larger than one 
full 
track.
 
I once wrote a deblocker program to read in 640K tape blocks and break  them 
up into QSAM-friendly chunks of 32,760 bytes or less.  It was an  interesting 
exercise, made even more so by having to run it on MVS under  VM, which caused 
a lot of unrepeatable chaining check errors due to the  very long channel 
program to read in 640K in one I/O  request.





Bill  Fairchild

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[willie bunter]

Thanks Eric for taking the time to explain and provide me samples of your jcls. 
 I will look them over and should I have any questions could I kindly impose 
upon your good offices?  As you can see it is Saturday night and I am working.  
Such is the life as we have ALL have done.
   
  P.S. I think I am gettting too old for this.  But a pay cheque is a pay 
cheque 
   
  Thanks again.

Eric Bielefeld <[EMAIL PROTECTED]> wrote:
  Willie,

I'll try to answer all of your questions. I'll do this one from the
listserve web site, as it doesn't time out like my Roadrunner Email account
does when I take a little too long to reply. I found some of my old JCL,
so I'll cut and paste that for the catalog moves.

1. I think all of the IMS files were moved using the application backup
software. I think we use a product from BMC that does faster backups and
restores. We changed all of the delete defines for all of the master
files, and the next time they were reorged, they would go to the 3390
volume.

2. We have almost no SMS managed data. As in 1 above, we changed the
delete defines, which then had the new volser hard coded.

3. I don't remember how I moved the MCAT, but I think I built a new one,
and then just changed the catalog pointer in the LOAD00 member to point to
the new catalog. We have very little volatility in our MCAT.

4. The user catalogs were all done on the weekend just before or after the
IPL. Here are 4 jobs I ran to move a single catalog. I kept the name of
each UCAT the same, as that seemed simpler. Here are the jobs:

//TSYS2001 JOB (6377,TSO,),'MOVE LIB CAT 1',
// NOTIFY=TSYS200,
// CLASS=4,MSGCLASS=X,MSGLEVEL=(1,1)
//**
//* MOVE LIB CAT JOB 1
//**
//MOVECAT EXEC PGM=IDCAMS
//EXPDD DD DSN=TSYS200.EXPORT.VLIB001,DISP=(NEW,CATLG),UNIT=TSO,
// SPACE=(CYL,(15,5),RLSE)
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
EXPORT SYS1.USERCAT.VLIB001 OUTFILE(EXPDD) TEMPORARY
/*
//TSYS2002 JOB (6377,TSO,),'MOVE LIB CAT 2',
// NOTIFY=TSYS200,
// CLASS=4,MSGCLASS=X,MSGLEVEL=(1,1)
//**
//* MOVE LIB CAT JOB 2
//**
//MOVECAT EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
DELETE SYS1.USERCAT.VLIB001 RECOVERY USERCATALOG
/*
//TSYS2003 JOB (6377,TSO,),'LIBCAT DEFINE JOB 3 ',MSGCLASS=X,
// CLASS=2,NOTIFY=TSYS200
//*
//* LIB: IPO1.JCLLIB(ICFUCAT)
//* GDE: CBIPO MVS CUSTOMIZATION
//* DOC: DEFINE AN ICF USER CATALOG
//*
//DEFINE1 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//VOL DD UNIT=3390,VOL=SER=LIB901,DISP=OLD
//SYSIN DD *
DEFINE USERCATALOG -
(NAME(SYS1.USERCAT.VLIB001) -
CYLINDERS(20 5) -
VOLUME(LIB901) -
CONTROLINTERVALSIZE(4096) -
BUFND(4) -
BUFNI(4) -
STRNO(3) -
NOIMBED -
NOREPLICATE -
FREESPACE(20 20) -
RECORDSIZE(4086 32400) -
ICFCATALOG -
FILE(VOL)) -
CATALOG(SYS1.MCAT.VHSPCAT)
/*
//TSYS2004 JOB (6377,TSO,),'MOVE LIBCAT JOB 4',
// NOTIFY=TSYS200,
// CLASS=4,MSGCLASS=X,MSGLEVEL=(1,1)
//**
//* MOVE CAT JOB 4
//**
//MOVECAT EXEC PGM=IDCAMS
//EXPDD DD DSN=TSYS200.EXPORT.VLIB001,DISP=OLD
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
IMPORT INFILE(EXPDD) -
OUTDATASET(SYS1.USERCAT.VLIB001) -
ALIAS UNLOCK INTOEMPTY
/*

I hope that helps.

Eric Bielefeld
P&H Mining Equipment




-
New Yahoo! Messenger with Voice. Call regular phones from your PC for low, low 
rates.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 03/24/2006
   at 08:13 PM, John Eells <[EMAIL PROTECTED]> said:

>There are three kinds of blocks: Fixed, Variable, and Undefined.

I realize that it doesn't get much[1] use, but there is a fourth type
of block. Is it restricted to tape?

[1] Actually, I wouldn't guaranty that ANSI format gets *any* use.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 03/25/2006
   at 10:41 AM, Ron and Jenny Hawkins <[EMAIL PROTECTED]> said:

>The Text records may be 256 bytes, but they are blocked, and the
>Blocksize of the "text" block will be up to the blksize of the
>loadlib.

WTF? Everything *but* text records is 256 bytes, and nothing is
blocked. Text records are usually as large as the csect, although they
may have to be split due to blksize or remaining track capacity.

>2) There was a fix for IEBCOPY years ago where "FAT RECORSS" were
>causing a problem. FAT records were caused where modules were
>created with text blocks larger than the Loadlib blksize. This
>couldn't happen if text records were not blocked.

Of course it could and did happen, because a single record was larger
than blksize. By definition RECFM=U is unblocked.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 03/25/2006
   at 01:16 PM, "(IBM Mainframe Discussion List)" <[EMAIL PROTECTED]>
said:

>But you can have any number of CCWs, each transferring 65,535  bytes
>and using  data chaining, to make a much larger block than 64K.

As long as your channel is fast enough to avoid data overrun.

Then there's LBI.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 03/24/2006
   at 11:27 AM, Gerhard Adam <[EMAIL PROTECTED]> said:

>Single CSECT load modules are almost never large enough to use the
>maximum  (32760) since that would require 8 base registers,

No it wouldn't. You're making un warranted assumptions about what is
in the CSECT.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Ron and Jenny Hawkins]

Seymour,

The text blocks appear as a continuous byte stream, but this is the
unformatted representation of the text records, where each record is machine
instruction.

It's probably a case of semantics and/or context as to whether text in an
object is a block of machine instructions, or a record unto itself. 

When I said "may be 256 bytes" I was referring to the size of the
instruction "record," and I probably would have been more accurate to say
"up to 256 bytes."

Ron

> 
> WTF? Everything *but* text records is 256 bytes, and nothing is
> blocked. Text records are usually as large as the csect, although they
> may have to be split due to blksize or remaining track capacity.
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Ron and Jenny Hawkins]

Adam,

I certainly wouldn't be leading a crusade to reblock load libraries to save
space either. In most shops they make up a very small percentage of the
total space. I'm more interested in good practices when creating a loadlib.

I have always reblocked active load libraries, with some quantifiably good
results, and sometimes with no change whatsoever. Again it is not a crusade,
it is focused tuning. Starting out with 32760 as a Blocksize for loadlibs
means you don't have to go back and change it later.

There were many papers on this topic from the early days of XA fetch through
to the mid 90s when cache helped give fetch a bit of a boost. The following
is from a paper you may know:

"The effect of blocking, apart from device utilisation, can affect 
Program Fetch performance.  Small blocksizes will not conserve 
storage, since 96K is always fixed for Program Fetch buffers, but 
it may adversely affect performance.  When a program is fetched, 
one text record and up to 48 RLD/control records are read in each 
I/O operation.  PCI interrupt is used to add CCWs dynamically 
and having larger text blocks allows more time for this activity."

The performance impact is less in cache controllers, but it still exists and
32760 is a reasonably easy way to ensure that fetch performance is optimal.

Ron

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 03/28/2006
   at 01:57 AM, Ron and Jenny Hawkins <[EMAIL PROTECTED]> said:

>The text blocks appear as a continuous byte stream, but this is the
>unformatted representation of the text records, where each record is
>machine instruction.

I'm not sure what you're trying to say there. A text record is a
storage image with no additional control information: it can be read
directly in place. There is no issue of formatted versus unformatted.

>When I said "may be 256 bytes" I was referring to the size of the
>instruction "record,"

What instruction record? Machine instructions are in a text record,
which is not limited to 256 bytes.

>and I probably would have been more accurate to say
>"up to 256 bytes."

No, because text records are *not* limited to 256 bytes. You're
confusing them with other records, e.g., Control, RLD.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Ron and Jenny Hawkins]

No I'm not.

> 
> No, because text records are *not* limited to 256 bytes. You're
> confusing them with other records, e.g., Control, RLD.
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Kirk Talman]

Since this thread will not die, I would like to comment about the various 
opinions on blksize of loadlibs.

Our large production loadlibs (>10,000 trks used) contain mostly Cobol 
modules that support various combinations of DB2 IMS CICS MQ.  The module 
sizes vary downward from X'35' - about 3 meg.  The number of records 
for that module is 289.  With that many TXT records, I don't understand 
why one would use other than 1/2 trk blocking (27998 for "3390")?  This is 
especially true in our environment since there are three of these 
libraries existing on each of 11 production plexes.  As Everett Dirkson 
once almost said, a gigabit here a gigabit there and soon you're talking 
real storage. (all puns intended)

curious pup


-
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom
it is addressed.  The information may also constitute a legally
privileged confidential communication.  If the reader of this
message is not the intended recipient or an agent responsible for
delivering it to the intended recipient, you are hereby notified
that you have received this communication in error and that any
review, dissemination, copying, or unauthorized use of this
information, or the taking of any action in reliance on the
contents of this information is strictly prohibited.  If you have
received this communication in error, please notify us immediately
by e-mail, and delete the original message.  Thank you

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Hal Merritt]

Because load libraries are *not* RECFM F, FB, V, VB, or VBS. The binder
works to fill tracks and will tailor 'records' to fit the output device
subject to your specified or defaulted maximums. IEBCOPY COPYMOD does
the same, IIRC. 

I see every reason to always specify no less than the maximum possible
physical record size ('block size') for the emulated device. Again, the
binder will adjust the size of a given record size downward to fill the
track if needed. Admittedly, the benefit may be limited to the case
where the last chunk of the program is greater than half track and less
than the maximum. But you would eliminate an I/O now and then, and
*every* I/O counts.

My 0.02USD

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Kirk Talman
Sent: Tuesday, March 28, 2006 10:47 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: 3380-3390 Conversion - DISAPPOINTMENT

Since this thread will not die, I would like to comment about the
various 
opinions on blksize of loadlibs.

Our large production loadlibs (>10,000 trks used) contain mostly Cobol 
modules that support various combinations of DB2 IMS CICS MQ.  The
module 
sizes vary downward from X'35' - about 3 meg.  The number of records

for that module is 289.  With that many TXT records, I don't understand 
why one would use other than 1/2 trk blocking (27998 for "3390")?  This
is 
especially true in our environment since there are three of these 
libraries existing on each of 11 production plexes.  As Everett Dirkson 
once almost said, a gigabit here a gigabit there and soon you're talking

real storage. (all puns intended)

curious pup

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Ted MacNEIL]

>With that many TXT records, I don't understand 
why one would use other than 1/2 trk blocking (27998 for "3390")?

You missed a point (or two).

The block is undefined.
The block size is the maximum size a txt record can be.
TXT records can be longer than 'regular' records.
With today's DASD prices, the discussion is moot.

-
-teD

I’m an enthusiastic proselytiser of the universal panacea I believe in!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 03/29/2006
   at 12:35 AM, Ron and Jenny Hawkins <[EMAIL PROTECTED]> said:

>No I'm not.

Then where do you get the idea that the number 256 has anything to do
with text record sizes?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Ron and Jenny Hawkins]

Seymour,

To follow your way of thinking there is only one text record which is
simply, broken up into pieces on Blocksize and track boundaries, ignoring
the instruction records within the block. The reality is that the linkage
editor and Copymod are processing Instructions records and will split the
text block on an instruction record boundary.

Where do I get the idea that the number 256 has anything to do with text
record sizes? Well, last time I looked that is the largest size of an
instruction record.

Now, if the Text in a load module is not a block of instruction records, why
would the linkage Editor and Copymod bother to check for a record boundary
before writing the text block?

As it is, IBM don't really seem to be consistent with their own use of
Potato and Potato. Once a block gets on a disk it is a record, so go figure!


If you feel you are so correct then I suggest you ask IBM to correct
paragraphs like in the DFSMS Utilities Manual.

"IEBCOPY will determine the amount of space remaining on a track
before assigning a size to the next block to be written. If this
amount is smaller than the output block size, IEBCOPY will try to
determine if a smaller block can be written to use the remaining
space
on the track. The maximum block size produced by the COPYMOD
function
is 32760 bytes."

Anyway Seymour, It's your dog and the devils in the de tail. My potato and
your potato actually don't change the performance of fetch, or the size of a
loadlib.

Ron

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Shmuel Metz (Seymour J.)
> Sent: Wednesday, 29 March 2006 10:11 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: 3380-3390 Conversion - DISAPPOINTMENT
> 
> In <[EMAIL PROTECTED]>, on 03/29/2006
>at 12:35 AM, Ron and Jenny Hawkins <[EMAIL PROTECTED]> said:
> 
> >No I'm not.
> 
> Then where do you get the idea that the number 256 has anything to do
> with text record sizes?
> 
> --
>  Shmuel (Seymour J.) Metz, SysProg and JOAT
>  ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
> We don't care. We don't have to care, we're Congress.
> (S877: The Shut up and Eat Your spam act of 2003)
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Gerhard Postpischil]

Ron and Jenny Hawkins wrote:

Seymour,

To follow your way of thinking there is only one text record which is
simply, broken up into pieces on Blocksize and track boundaries, ignoring
the instruction records within the block. The reality is that the linkage
editor and Copymod are processing Instructions records and will split the
text block on an instruction record boundary.


I'm going to jump in here, because you're talking at cross-purposes. 
Seymour uses the IBM names for defined record, which do not include 
"instruction record". There is one record type limited to 256 bytes, and 
that's the control record; the larger size records up to 32760 bytes are 
named text records. Text records do not contain length indicators, 
flags, or anything other than instructions and data (although areas 
described by DS or skipped by ORG may contain garbage). Text records are 
written to fit track geometry, and could very well split an instruction 
(only section boundaries are relevant, as they require matching 
information in the preceding control record).



Where do I get the idea that the number 256 has anything to do with text
record sizes? Well, last time I looked that is the largest size of an
instruction record.


But what do you mean by an "instruction record"? Unless you use common 
terms, you're just wasting everybody's time. Text records may be longer 
then 256; control records will never exceed that (pending redesign of 
the Operating System and components, which could happen in the Binder).



Now, if the Text in a load module is not a block of instruction records, why
would the linkage Editor and Copymod bother to check for a record boundary
before writing the text block?


They don't, and the text records also contain data and reserved space.


Gerhard Postpischil
Bradford, Vt

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 04/01/2006
   at 04:45 PM, Ron and Jenny Hawkins <[EMAIL PROTECTED]> said:

>To follow your way of thinking there is only one text record which is
>simply, broken up into pieces on Blocksize and track boundaries,
>ignoring the instruction records within the block.

That doesn't follow either Linkage Editor nomenclature or Linkage
Editor behavior. The documentation uses "record" to refer to the same
thing as the access method calls a record, and the Linkage Editor
never writes consecutive text record; it always writes a CTL or
CTL/RLD record between text records.

>Where do I get the idea that the number 256 has anything to do with
>text record sizes? Well, last time I looked that is the largest size
>of an instruction record.

What do you mean by an "instruction record"?

>Now, if the Text in a load module is not a block of instruction
>records, why would the linkage Editor and Copymod bother to check
>for a record boundary before writing the text block?

What gives you the idea that it does? It checks for end of csect and
for large gaps.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 04/01/2006
   at 04:22 PM, Gerhard Postpischil <[EMAIL PROTECTED]> said:

>There is one record type limited to 256 bytes, and 
>that's the control record; 

There are others, e.g., RLD.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Gerhard Postpischil]

Shmuel Metz (Seymour J.) wrote:
There is one record type limited to 256 bytes, and 
that's the control record; 



There are others, e.g., RLD.


RLD, CESD, IDR, etc. are all control records - you're just haggling over 
the price 


Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Ron and Jenny Hawkins]

Gerhard/Shmuel,

Where ever the reference I had to Text records splitting on instruction
boundaries is, I can no longer find. This may be another senior moment!
References I've found all reference CSECT boundaries as a point to terminate
text records.

So I consider myself better educated.

However, this still leaves me confused over IBM's constant reference to
blocking and reblocking of load modules. Does this make the authors as
stupid as me?

Ron

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Gerhard Postpischil]

Ron and Jenny Hawkins wrote:

However, this still leaves me confused over IBM's constant reference to
blocking and reblocking of load modules. Does this make the authors as
stupid as me?


Only in being confused by the language - when they refer to "blocking" 
of load modules, they are referring to setting/resetting the physical 
block size of text, not in the QSAM sense of combining records.


For example, if a single CSECT load module is 100K in size, the binder 
would write control records, then the largest text record that will fit 
on the remainder of the track, not larger than the blocksize, another 
control record, then more of the text record, repeated until all text 
has been written, and then an end-file record. When there are multiple 
CSECTs, it gets a little more complicated, but the scheme is basically 
the same.


When such a module is copied to a device with different track capacity, 
or to a different position on a track, COPYMOD will change the text 
sizes to be as large as possible again, resulting in a physical layout 
that may be different from the source. Control records may be added or 
omitted as necessary, and module load time may change, but it will 
remain functionally equivalent.


Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 04/02/2006
   at 02:31 PM, Gerhard Postpischil <[EMAIL PROTECTED]> said:

>RLD, CESD, IDR, etc. are all control records - you're just haggling
>over  the price 

Then how do you distinguish CTL from the others?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 3380-3390 Conversion - DISAPPOINTMENT

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 04/03/2006
   at 09:07 PM, Ron and Jenny Hawkins <[EMAIL PROTECTED]> said:

>However, this still leaves me confused over IBM's constant reference
>to blocking and reblocking of load modules. Does this make the
>authors as stupid as me?

The authors regard the csect as the basic unit of data. You're used to
thinking of records being smaller than blocks, but think of load
modules as analogous to RECFM=VBS with a small block size and a large
record size. The (large) csect is written out as multiple blocks,
separated by CTL or CTL/RLD records.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html