File sizing introduction - Revision history

Admin: Admin moved page File size calculation to File sizing introduction without leaving a redirect: Better reflection of the content of the page and less confusion with other file sizing page

2015-04-13T18:45:11Z

Admin moved page File size calculation to File sizing introduction without leaving a redirect: Better reflection of the content of the page and less confusion with other file sizing page

← Older revision	Revision as of 18:45, 13 April 2015
(No difference)

Dme at 04:29, 10 May 2014

2014-05-10T04:29:16Z

← Older revision		Revision as of 04:29, 10 May 2014
Line 1:		Line 1:
	==Overview: two approaches to file sizing==		==Overview: two approaches to file sizing==
	<p>		<p>
	After designing the data structures you are implementing (see [[Field design ~~(File management)\|field~~]] and [[Field ~~group design (File management)\|field~~ group design]]) there are two ways for a file manager to approach the calculation of file sizes:</p>		After designing the data structures you are implementing (see [[Field design]] and [[Field group design]]) there are two ways for a file manager to approach the calculation of file sizes:</p>
	<p>		<p>
	You can take the ad-hoc approach, by making sizing estimates and doing one or a combination of these:</p>		You can take the ad-hoc approach, by making sizing estimates and doing one or a combination of these:</p>

DmeWiccan: Automatically generated page update

2014-05-09T22:45:47Z

Automatically generated page update

← Older revision		Revision as of 22:45, 9 May 2014
Line 43:		Line 43:
	<p>Unless space is at a premium, it is a good idea to define larger data set(s) than you need, which gives you the ability to automatically, or manually, increase the Tables without issue.</p>		<p>Unless space is at a premium, it is a good idea to define larger data set(s) than you need, which gives you the ability to automatically, or manually, increase the Tables without issue.</p>

	[[Category:~~File management~~]]		[[Category:Model 204 files]]

JAL: /* CSIZE parameter */

2014-04-04T18:45:21Z

CSIZE parameter

← Older revision		Revision as of 18:45, 4 April 2014
Line 31:		Line 31:
	===CSIZE parameter===		===CSIZE parameter===
	<p>		<p>
	Like the internal file dictionary, Table C is hashed and so ~~can not~~ be dynamically changed.</p>		Like the internal file dictionary, Table C is hashed and so cannot be dynamically changed.</p>

	<p>The easiest way to make sure that this is an issue is not to define any <var>KEY</var> or <var>NUMERIC RANGE</var> fields: make them ordered instead. This has the associated advantage, if you use <var>[[FILEORG parameter\|FILEORG]]</var> X'100' files, of permitting as many as ~~32000~~ field names in a file.</p>		<p>The easiest way to make sure that this is an issue is not to define any <var>KEY</var> or <var>NUMERIC RANGE</var> fields: make them ordered instead. This has the associated advantage, if you use <var>[[FILEORG parameter\|FILEORG]]</var> X'100' files, of permitting as many as 32,000 field names in a file.</p>

	===Number of data sets===		===Number of data sets===

JAL: /* ATRPG and ASTRPPG parameters */

2014-03-21T16:00:53Z

ATRPG and ASTRPPG parameters

← Older revision		Revision as of 16:00, 21 March 2014
Line 27:		Line 27:
	Because the [[Table A (File architecture)#Internal File Dictionary\|Internal File Dictionary]] is hashed, it can only be resized by reorganizing/recreating the file. This involves an outage of the Online, so it should be avoided.</p>		Because the [[Table A (File architecture)#Internal File Dictionary\|Internal File Dictionary]] is hashed, it can only be resized by reorganizing/recreating the file. This involves an outage of the Online, so it should be avoided.</p>

	<p>You can look at the detailed calculation rules at [[File size calculation in detail#Sizing Table A\|Sizing Table A]] or, given how small Table A is compared to the other tables, round up on your rough estimate for <var>[[ATRPG parameter\|ATRPG]]</var> and round down (to try and fit fewer field definitions on each Table A page) for <var>[[ASTRPPG parameter\|ASTRPPG]]</var>.</p>		<p>You can look at the detailed calculation rules at [[File size calculation in detail#Sizing Table A\|Sizing Table A]] or, given how small Table A is compared to the other tables, round up on your rough estimate for <var>[[ATRPG parameter\|ATRPG]]</var> and round down (to try and fit fewer field definitions on each Table A page) for <var>[[ASTRPPG parameter\|ASTRPPG]]</var>.</p>


	===CSIZE parameter===		===CSIZE parameter===

JAL at 23:21, 18 February 2014

2014-02-18T23:21:09Z

← Older revision		Revision as of 23:21, 18 February 2014
Line 1:		Line 1:
	==Overview ~~- Two~~ approaches to ~~File Sizing~~==		==Overview: two approaches to file sizing==
	<p>After designing the data structures you are implementing (see [[Field design (File management)\|field]] and [[Field group design (File management)\|field group design]]) there are two ways for a file manager to approach the calculation of file sizes:</p>		<p>
			After designing the data structures you are implementing (see [[Field design (File management)\|field]] and [[Field group design (File management)\|field group design]]) there are two ways for a file manager to approach the calculation of file sizes:</p>
			<p>
			You can take the ad-hoc approach, by making sizing estimates and doing one or a combination of these:</p>
			<ul>
			<li>Iteratively load a sampling of records to verify</li>
			<li>Use the development and testing process to make final sizing decisions</li>
			</ul>

	<p>~~You~~ can ~~take~~ the ~~ad-hoc approach~~, ~~by making sizing estimates~~ and ~~either:~~</p>		<p>Alternatively, you can do a detailed analysis of the data you expect the file to contain, and try to derive precise sizes for the Model 204 tables, a laborious process.</p>

	* iteratively load a sampling of records to verify		==Choosing an approach==
	* use the development and testing process to make final sizing decisions		<p>
			Most Model 204 file managers use the ad-hoc design approach. Often there is already a production file with similar characteristics to the new file you are creating. Simply copying its parameters as a starting point is a quick way to get a file ready for development and testing.</p>
	~~<p>or, of course, a combination of both.</p>~~

	~~<p>Alternatively, you can do a detailed analysis of the data you expect the file to contain, and try and derive precise sizes for the Model 204 tables, a laborious process.</p>~~

	==Choosing an ~~Approach~~==

	<p>Most Model 204 file managers use the ad-hoc design approach. Often there is already a production file with similar characteristics to the new file you are creating. Simply copying its parameters as a starting point is a quick way to get a file ready for development and testing.</p>

	<p>Moreover, most of the sizes can be easily changed dynamically, so an extreme level of precision is not overly important.</p>		<p>Moreover, most of the sizes can be easily changed dynamically, so an extreme level of precision is not overly important.</p>

	<p>However, it is valuable for a file manager to be grounded in the principles of Model 204 file size calculation. ~~So, to~~ use (or just understand) the sizing rules, see [[File size calculation in detail]]. </p>		<p>However, it is valuable for a file manager to be grounded in the principles of Model 204 file size calculation. To use (or just understand) the sizing rules, see [[File size calculation in detail]]. </p>

	~~==Critical, Up Front Decisions==~~

	~~<p>There are, however, certain decisions which are more difficult to fix and so should be as 'correct' as possible, as early as possible:</p>~~


	~~<b>[[ATRPG parameter\|ATRPG]] and [[ASTRPPG parameter]]s</b>~~

	<p>Because the [[Table A (File architecture)#Internal File Dictionary\|Internal File Dictionary]] is hashed, it can only be resized by reorganizing / recreating the file. This involves an outage of the online, and so should be avoided.</p>

	<p>You can look at the detailed calculation rules at [[File size calculation in detail#Sizing Table A\|Sizing Table A]] or, given how small Table A is compared to the other tables, round up on your rough estimate for [[ATRPG parameter\|ATRPG]] and round down (to try and fit fewer field definitions on each Table A page) for [[ASTRPPG parameter\|ASTRPPG]].</p>


	<b>~~[[CSIZE parameter]]~~</b>		==Critical, up-front decisions==
			<p>
			Because certain decisions are more difficult to fix, they must be as "correct" as possible, as early as possible. These are described in the sections that follow.</p>

	<p>~~Like~~ the ~~internal file dictionary,~~ Table C is hashed ~~and~~ so ~~can not~~ be ~~dynamically changed~~.</p>		===ATRPG and ASTRPPG parameters===
			<p>
			Because the [[Table A (File architecture)#Internal File Dictionary\|Internal File Dictionary]] is hashed, it can only be resized by reorganizing/recreating the file. This involves an outage of the Online, so it should be avoided.</p>

	<p>~~The easiest way to make sure that this is an issue~~ is ~~not~~ to ~~define any KEY or NUMERIC RANGE fields: make them ordered instead. This has~~ the ~~associated advantage of~~, ~~if you use~~ [[~~FILEORG~~ parameter\|~~FILEORG~~]] ~~x'100' files, of permitting up~~ to ~~32000~~ field ~~names in a file~~.</p>		<p>You can look at the detailed calculation rules at [[File size calculation in detail#Sizing Table A\|Sizing Table A]] or, given how small Table A is compared to the other tables, round up on your rough estimate for <var>[[ATRPG parameter\|ATRPG]]</var> and round down (to try and fit fewer field definitions on each Table A page) for <var>[[ASTRPPG parameter\|ASTRPPG]]</var>.</p>


	<b>~~Number of Datasets~~</b>		===CSIZE parameter===
			<p>
			Like the internal file dictionary, Table C is hashed and so can not be dynamically changed.</p>

	<p>~~You can dynamically~~ [[~~INCREASE command~~\|~~add datasets~~]] to a ~~Model 204~~ file.</p>		<p>The easiest way to make sure that this is an issue is not to define any <var>KEY</var> or <var>NUMERIC RANGE</var> fields: make them ordered instead. This has the associated advantage, if you use <var>[[FILEORG parameter\|FILEORG]]</var> X'100' files, of permitting as many as 32000 field names in a file.</p>

	<p>~~The reason that it is better not have~~ to ~~is that there may be JCL containing~~ file ~~references which would need to be updated at the same time~~.</p>		===Number of data sets===
			<p>
			You can dynamically [[INCREASE command\|add datasets]] to a Model 204 file.</p>

	<p>~~Unless space~~ is ~~at a premium~~, ~~it is a good idea to define dataset(s) larger than you~~ need~~, which gives you the ability~~ to ~~automatically, or manually, increase~~ the ~~Tables without issue~~.</p>		<p>It is better not to have to do this, because there may be JCL containing file references that would need to be updated at the same time.</p>

			<p>Unless space is at a premium, it is a good idea to define larger data set(s) than you need, which gives you the ability to automatically, or manually, increase the Tables without issue.</p>

	[[Category:File management]]		[[Category:File management]]

Admin at 22:12, 18 December 2013

2013-12-18T22:12:22Z

← Older revision		Revision as of 22:12, 18 December 2013
Line 26:		Line 26:
	<b>[[ATRPG parameter\|ATRPG]] and [[ASTRPPG parameter]]s</b>		<b>[[ATRPG parameter\|ATRPG]] and [[ASTRPPG parameter]]s</b>

	<p>Because the [[Table A (File ~~Architecture~~)#Internal File Dictionary\|Internal File Dictionary]] is hashed, it can only be resized by reorganizing / recreating the file. This involves an outage of the online, and so should be avoided.</p>		<p>Because the [[Table A (File architecture)#Internal File Dictionary\|Internal File Dictionary]] is hashed, it can only be resized by reorganizing / recreating the file. This involves an outage of the online, and so should be avoided.</p>

	<p>You can look at the detailed calculation rules at [[File size calculation in detail#Sizing Table A\|Sizing Table A]] or, given how small Table A is compared to the other tables, round up on your rough estimate for [[ATRPG parameter\|ATRPG]] and round down (to try and fit fewer field definitions on each Table A page) for [[ASTRPPG parameter\|ASTRPPG]].</p>		<p>You can look at the detailed calculation rules at [[File size calculation in detail#Sizing Table A\|Sizing Table A]] or, given how small Table A is compared to the other tables, round up on your rough estimate for [[ATRPG parameter\|ATRPG]] and round down (to try and fit fewer field definitions on each Table A page) for [[ASTRPPG parameter\|ASTRPPG]].</p>

ELowell at 19:56, 16 December 2013

2013-12-16T19:56:30Z

← Older revision		Revision as of 19:56, 16 December 2013
Line 1:		Line 1:
	==Overview - Two approaches to File Sizing==		==Overview - Two approaches to File Sizing==
	<p>After designing the data structures you are implementing (see [[Field ~~Design~~ (File ~~Management~~)\|field]] and [[Field group design (File management)\|~~Field~~ group design]]) there are two ways for a file manager to approach the calculation of file sizes:</p>		<p>After designing the data structures you are implementing (see [[Field design (File management)\|field]] and [[Field group design (File management)\|field group design]]) there are two ways for a file manager to approach the calculation of file sizes:</p>

	<p>You can take the ad-hoc approach, by making sizing estimates and either:</p>		<p>You can take the ad-hoc approach, by making sizing estimates and either:</p>

ELowell at 19:15, 16 December 2013

2013-12-16T19:15:21Z

← Older revision		Revision as of 19:15, 16 December 2013
Line 1:		Line 1:
	==Overview - Two approaches to File Sizing==		==Overview - Two approaches to File Sizing==
	<p>After designing the data structures you are implementing (see [[Field Design (File Management)\|field]] and [[Field ~~Group Design~~ (File ~~Management~~)\|Field ~~Group~~ design]]) there are two ways for a file manager to approach the calculation of file sizes:</p>		<p>After designing the data structures you are implementing (see [[Field Design (File Management)\|field]] and [[Field group design (File management)\|Field group design]]) there are two ways for a file manager to approach the calculation of file sizes:</p>

	<p>You can take the ad-hoc approach, by making sizing estimates and either:</p>		<p>You can take the ad-hoc approach, by making sizing estimates and either:</p>

Admin at 19:27, 12 December 2013

2013-12-12T19:27:17Z

← Older revision		Revision as of 19:27, 12 December 2013
Line 17:		Line 17:
	<p>Moreover, most of the sizes can be easily changed dynamically, so an extreme level of precision is not overly important.</p>		<p>Moreover, most of the sizes can be easily changed dynamically, so an extreme level of precision is not overly important.</p>

	<p>However, it is valuable for a file manager to be grounded in the principles of Model 204 file size calculation. So, to use (or just understand) the sizing rules, see [[File ~~Size Calculation~~ in ~~Detail~~]]. </p>		<p>However, it is valuable for a file manager to be grounded in the principles of Model 204 file size calculation. So, to use (or just understand) the sizing rules, see [[File size calculation in detail]]. </p>

	==Critical, Up Front Decisions==		==Critical, Up Front Decisions==
Line 28:		Line 28:
	<p>Because the [[Table A (File Architecture)#Internal File Dictionary\|Internal File Dictionary]] is hashed, it can only be resized by reorganizing / recreating the file. This involves an outage of the online, and so should be avoided.</p>		<p>Because the [[Table A (File Architecture)#Internal File Dictionary\|Internal File Dictionary]] is hashed, it can only be resized by reorganizing / recreating the file. This involves an outage of the online, and so should be avoided.</p>

	<p>You can look at the detailed calculation rules at [[File ~~Size Calculation~~ in ~~Detail~~#Sizing Table A\|Sizing Table A]] or, given how small Table A is compared to the other tables, round up on your rough estimate for [[ATRPG parameter\|ATRPG]] and round down (to try and fit fewer field definitions on each Table A page) for [[ASTRPPG parameter\|ASTRPPG]].</p>		<p>You can look at the detailed calculation rules at [[File size calculation in detail#Sizing Table A\|Sizing Table A]] or, given how small Table A is compared to the other tables, round up on your rough estimate for [[ATRPG parameter\|ATRPG]] and round down (to try and fit fewer field definitions on each Table A page) for [[ASTRPPG parameter\|ASTRPPG]].</p>

← Older revision		Revision as of 22:12, 18 December 2013
Line 26:		Line 26:
	<b>[[ATRPG parameter\|ATRPG]] and [[ASTRPPG parameter]]s</b>		<b>[[ATRPG parameter\|ATRPG]] and [[ASTRPPG parameter]]s</b>

	<p>Because the [[Table A (File ~~Architecture~~)#Internal File Dictionary\|Internal File Dictionary]] is hashed, it can only be resized by reorganizing / recreating the file. This involves an outage of the online, and so should be avoided.</p>		<p>Because the [[Table A (File architecture)#Internal File Dictionary\|Internal File Dictionary]] is hashed, it can only be resized by reorganizing / recreating the file. This involves an outage of the online, and so should be avoided.</p>

	<p>You can look at the detailed calculation rules at [[File size calculation in detail#Sizing Table A\|Sizing Table A]] or, given how small Table A is compared to the other tables, round up on your rough estimate for [[ATRPG parameter\|ATRPG]] and round down (to try and fit fewer field definitions on each Table A page) for [[ASTRPPG parameter\|ASTRPPG]].</p>		<p>You can look at the detailed calculation rules at [[File size calculation in detail#Sizing Table A\|Sizing Table A]] or, given how small Table A is compared to the other tables, round up on your rough estimate for [[ATRPG parameter\|ATRPG]] and round down (to try and fit fewer field definitions on each Table A page) for [[ASTRPPG parameter\|ASTRPPG]].</p>