User:Msw/Testbed - Revision history

Msw: /* Database tables in single-level storage */

2022-06-16T13:30:28Z

Database tables in single-level storage

← Older revision		Revision as of 15:30, 16 June 2022
Line 140:		Line 140:
	Conceptually, the rows of data in an AS/400 database physical file member (aka. an MI data space) are laid out, one column after another, and one row after another, just like a big array in virtual storage. So, to fetch a given row from any particular database table (or file), one needs only to know the starting address of the first row and the total record length. Multiply the record length times the desired record number, and add that to the base address and you have computed the address of the desired data in virtual memory (SLS). Then it is simply a matter of paging in the desired page(s).		Conceptually, the rows of data in an AS/400 database physical file member (aka. an MI data space) are laid out, one column after another, and one row after another, just like a big array in virtual storage. So, to fetch a given row from any particular database table (or file), one needs only to know the starting address of the first row and the total record length. Multiply the record length times the desired record number, and add that to the base address and you have computed the address of the desired data in virtual memory (SLS). Then it is simply a matter of paging in the desired page(s).

	In reality, it is not quite that simple, but almost. IBM added ~~the~~ specialized MI instructions for database management, journal management, and commitment control, to permit safe concurrent access to and updating of the data in database tables (files) across the entire platform (by many interactive and batch jobs, accessing the same database table at the same time.)		In reality, it is not quite that simple, but almost. IBM added specialized MI instructions for database management, journal management, and commitment control, to permit safe concurrent access to and updating of the data in database tables (files) across the entire platform (by many interactive and batch jobs, accessing the same database table at the same time.)

	=== Disk Allocations ===		=== Disk Allocations ===

Msw: /* Database tables in virtual memory */

2022-06-16T13:29:22Z

Database tables in virtual memory

← Older revision		Revision as of 15:29, 16 June 2022
Line 136:		Line 136:
	Another advantage of this SLS approach is the ability to do very fast context switches.<ref>According to Frank Soltis in his books ''Inside the AS/400'', and ''Fortress Rochester''.</ref> This is the reason why even older slower IMPI machines with 100 % loaded CPU still provided astonishingly fast interactive response times, when compared with other common platforms of that era.		Another advantage of this SLS approach is the ability to do very fast context switches.<ref>According to Frank Soltis in his books ''Inside the AS/400'', and ''Fortress Rochester''.</ref> This is the reason why even older slower IMPI machines with 100 % loaded CPU still provided astonishingly fast interactive response times, when compared with other common platforms of that era.

	== Database tables in ~~virtual memory~~ ==		== Database tables in single-level storage ==

	Conceptually, the rows of data in an AS/400 database physical file member (aka. an MI data space) are laid out, one column after another, and one row after another, just like a big array in virtual storage. So, to fetch a given row from any particular database table (or file), one needs only to know the starting address of the first row and the total record length. Multiply the record length times the desired record number, and add that to the base address and you have computed the address of the desired data in virtual memory (SLS). Then it is simply a matter of paging in the desired page(s).		Conceptually, the rows of data in an AS/400 database physical file member (aka. an MI data space) are laid out, one column after another, and one row after another, just like a big array in virtual storage. So, to fetch a given row from any particular database table (or file), one needs only to know the starting address of the first row and the total record length. Multiply the record length times the desired record number, and add that to the base address and you have computed the address of the desired data in virtual memory (SLS). Then it is simply a matter of paging in the desired page(s).

Msw: /* Command Syntax */

2022-06-15T17:06:19Z

Command Syntax

← Older revision		Revision as of 19:06, 15 June 2022
Line 236:		Line 236:

	=== Command Syntax ===		=== Command Syntax ===
	OS/400 commands use a very IBM style syntax, similar to what is used for TSO CLISTs, and for IDCAMS (VSAM access method services), etc. Each command specifies command name, followed by one more more "keyword(value)" pairs. Some commands allow the first few keywords to be specified positionally, as follows:		OS/400 commands use a very IBM style syntax, similar to what is used for TSO CLISTs, and for IDCAMS (VSAM access method services), etc. Each command specifies command name, followed by one more more "keyword(value)" pairs.

			; DLTF FILE(MYLIB/MYFILE)

			or

			; DSPPFM FILE(FILE1) MBR(MEMBER01)


			Some commands allow the first few keywords to be specified positionally, as follows:

	; DLTF MYLIB/MYFILE		; DLTF MYLIB/MYFILE
Line 242:		Line 251:
	or		or

	; DSPPFM ~~MYLIB/MYFILE MYMBR~~		; DSPPFM FILE1 MEMBER01

Msw: /* OS/400 Command syntax */

2022-06-15T17:03:35Z

OS/400 Command syntax

← Older revision		Revision as of 19:03, 15 June 2022
Line 217:		Line 217:

	== OS/400 Command syntax ==		== OS/400 Command syntax ==
	Experienced users often prefer not to have to repeatedly navigate though nested menus, so commands may be entered on any command line rather than menu choices. The OS/400 commands consist of two or three parts, built of abbreviated English words. Abbreviations often take place by omitting vowels and shortening the result to three characters or less. The first part is typically a ''verb'' and the second ~~part a ''subject''~~, optionally followed by additional groups of (usually) three characters each. (Occasionally, only one or two characters is used for the final part.)		Experienced users often prefer not to have to repeatedly navigate though nested menus, so commands may be entered on any command line rather than menu choices. The OS/400 commands consist of two or three parts, built of abbreviated English words. Abbreviations often take place by omitting vowels and shortening the result to three characters or less. The first part is typically a ''verb'' and the second component designates an object type to act upon, optionally followed by additional groups of (usually) three characters each. (Occasionally, only one or two characters is used for the final part.) This is followed by zero or more parameters or arguments.

	A few examples may illustrate the previous statements:		A few examples may illustrate the previous statements:
Line 235:		Line 235:
	A very nice feature of OS/400 is the ability to type in a command name, and press F4=Prompt. This presents a "fill-in-the-blanks" form on the display screen.		A very nice feature of OS/400 is the ability to type in a command name, and press F4=Prompt. This presents a "fill-in-the-blanks" form on the display screen.

	Command syntax is a command, followed by one more more "keyword(value)" pairs. Some commands allow the first few keywords to be specified positionally, as follows:		=== Command Syntax ===
			OS/400 commands use a very IBM style syntax, similar to what is used for TSO CLISTs, and for IDCAMS (VSAM access method services), etc. Each command specifies command name, followed by one more more "keyword(value)" pairs. Some commands allow the first few keywords to be specified positionally, as follows:

	; DLTF MYLIB/MYFILE		; DLTF MYLIB/MYFILE

Msw: /* Predictable Command Naming */

2022-06-15T16:58:01Z

Predictable Command Naming

← Older revision		Revision as of 18:58, 15 June 2022
Line 216:		Line 216:
	See also: [[About Green Screens and mouse-clickable UIs]].		See also: [[About Green Screens and mouse-clickable UIs]].

	== ~~Predictable~~ Command ~~Naming~~ ==		== OS/400 Command syntax ==
	Experienced users often prefer not to have to repeatedly navigate though nested menus, so commands may be entered on any command line rather than menu choices. The OS/400 commands consist of two or three parts, built of abbreviated English words. Abbreviations often take place by omitting vowels and shortening the result to three characters or less. The first part is typically a ''verb'' and the second part a ''subject'', optionally followed by additional groups of (usually) three characters each. (Occasionally, only one or two characters is used for the final part.)		Experienced users often prefer not to have to repeatedly navigate though nested menus, so commands may be entered on any command line rather than menu choices. The OS/400 commands consist of two or three parts, built of abbreviated English words. Abbreviations often take place by omitting vowels and shortening the result to three characters or less. The first part is typically a ''verb'' and the second part a ''subject'', optionally followed by additional groups of (usually) three characters each. (Occasionally, only one or two characters is used for the final part.)

Line 231:		Line 231:
	: Display Messages (from Message Queue)		: Display Messages (from Message Queue)

	=== Prompting ===		=== Command Prompting ===

	A very nice feature of OS/400 is the ability to type in a command name, and press F4=Prompt. This presents a "fill-in-the-blanks" form on the display screen.		A very nice feature of OS/400 is the ability to type in a command name, and press F4=Prompt. This presents a "fill-in-the-blanks" form on the display screen.
Line 237:		Line 237:
	Command syntax is a command, followed by one more more "keyword(value)" pairs. Some commands allow the first few keywords to be specified positionally, as follows:		Command syntax is a command, followed by one more more "keyword(value)" pairs. Some commands allow the first few keywords to be specified positionally, as follows:

	; DLTF		; DLTF MYLIB/MYFILE
	: MYLIB/MYFILE

	or		or

	; DSPPFM		; DSPPFM MYLIB/MYFILE MYMBR
	: MYLIB/MYFILE MYMBR

Msw: /* Predictable Command Naming */

2022-06-15T16:56:19Z

Predictable Command Naming

← Older revision		Revision as of 18:56, 15 June 2022
Line 217:		Line 217:

	== Predictable Command Naming ==		== Predictable Command Naming ==
	Experienced users ~~who would~~ prefer not to have to repeatedly navigate though nested menus, commands may be entered on ~~the~~ command line ~~instead of~~ menu ~~numbers~~. ~~These~~ commands consist of two or three parts, built of abbreviated English words. Abbreviations often take place by omitting vowels and shortening the result to three characters or less. The first part is typically a ''verb'' and the second part a ''subject'', optionally followed by additional groups of (usually) three characters each. (Occasionally, only one or two characters is used for the final part.)		Experienced users often prefer not to have to repeatedly navigate though nested menus, so commands may be entered on any command line rather than menu choices. The OS/400 commands consist of two or three parts, built of abbreviated English words. Abbreviations often take place by omitting vowels and shortening the result to three characters or less. The first part is typically a ''verb'' and the second part a ''subject'', optionally followed by additional groups of (usually) three characters each. (Occasionally, only one or two characters is used for the final part.)

	A few examples may illustrate the previous statements:		A few examples may illustrate the previous statements:
Line 230:		Line 230:
	; dspmsg		; dspmsg
	: Display Messages (from Message Queue)		: Display Messages (from Message Queue)

			=== Prompting ===

			A very nice feature of OS/400 is the ability to type in a command name, and press F4=Prompt. This presents a "fill-in-the-blanks" form on the display screen.

			Command syntax is a command, followed by one more more "keyword(value)" pairs. Some commands allow the first few keywords to be specified positionally, as follows:

			; DLTF
			: MYLIB/MYFILE

			or

			; DSPPFM
			: MYLIB/MYFILE MYMBR


	See also [[wikipedia:IBM i Control Language\|IBM i Control Language]] and [[CL Tricks]].		See also [[wikipedia:IBM i Control Language\|IBM i Control Language]] and [[CL Tricks]].

Msw: /* Predictable Command Naming */

2022-06-15T16:51:44Z

Predictable Command Naming

← Older revision		Revision as of 18:51, 15 June 2022
Line 217:		Line 217:

	== Predictable Command Naming ==		== Predictable Command Naming ==
	~~For experienced~~ users who ~~won't~~ repeatedly navigate though nested menus, commands may be entered on the command line instead of menu numbers. These commands consist of two or ~~more~~ parts, built of abbreviated ~~english~~ words. Abbreviations often take place by omitting vowels and shortening the result to less ~~or equal four characters~~. The first ~~one being~~ a ''verb'' and the second ~~one~~ a ''subject'', optionally followed by ~~more building blocks~~.		Experienced users who would prefer not to have to repeatedly navigate though nested menus, commands may be entered on the command line instead of menu numbers. These commands consist of two or three parts, built of abbreviated English words. Abbreviations often take place by omitting vowels and shortening the result to three characters or less. The first part is typically a ''verb'' and the second part a ''subject'', optionally followed by additional groups of (usually) three characters each. (Occasionally, only one or two characters is used for the final part.)

	A few examples may illustrate the previous statements:		A few examples may illustrate the previous statements:

Msw: /* Disk Allocations */

2022-06-15T03:47:36Z

Disk Allocations

← Older revision		Revision as of 05:47, 15 June 2022
Line 147:		Line 147:
	This spreading of data has the same advantages and disadvantages as RAID 0:		This spreading of data has the same advantages and disadvantages as RAID 0:
	* with increasing count of disk arms, the chance that a given data block is located on an idle drive increases and thus decreases latency through exploiting parallelism: the more applications run, the more data can be picked up from individual disks, the more overall processing work can be done.		* with increasing count of disk arms, the chance that a given data block is located on an idle drive increases and thus decreases latency through exploiting parallelism: the more applications run, the more data can be picked up from individual disks, the more overall processing work can be done.
	* since data is located in the system just once, the failure of (at least) one disk has hard to predict ramifications. Objects become ''damaged'' because parts of them are no longer accessible.<ref>The necessity of a solid, and '''tested''' backup and restore concept is self-explanatory, but also emphasized in IBM documentation.</ref>		* since data is located in the system just once, the failure of (at least) one disk has hard to predict ramifications. Objects become ''damaged'' because parts of them are no longer accessible.<ref>The necessity of a solid, and '''tested''' backup and restore concept is self-explanatory, but also emphasized in IBM AS/400 documentation.</ref>

	From early on, the concept of a dedicated I/O processor allowed for easy implementation of ''data mirroring'', to compensate for data loss because of a malfunctioning disk drive through redundancy.		From early on, the concept of a dedicated I/O processor allowed for easy implementation of ''data mirroring'', to compensate for data loss because of a malfunctioning disk drive through redundancy. This was recognized early on as a weakness in System/38 CPF -- if you lost one disk drive, you lost the entire Single-Level Storage, and would have to re-load the entire system from the last known good set of back-up tapes. (Hence, the aforementioned emphasis in the IBM documentation of establishing good back-up procedures.)

	Later, the well-known RAID-~~Levels~~ have been made available through the availability of ~~dedicated storage controllers~~.		Later, the well-known RAID-5 and RAID-6 have been made available through the availability of DASD IOPs (I/O processors). IBM actually "invented" what we now know of as "RAID" on the System/38, where it was known as "parity" protection. For every two DASD volumes, a third volume of the same type and size was used to store the exclusive or of the same sectors from the first two drives. If you lose either drive A or B, you simply XOR the remaining value with the "parity" data to recreate the missing data. This allows a system to continue to run, with somewhat degraded performance, until the failed drive can be replaced. (A XOR B -> C. B XOR C -> A; A XOR C -> B.) Modern RAID schemes with striping etc., are just more elaborate schemes using the same underlying concepts and principles of overlapping parity, similar to the ECC error correcting codes used in memory chips, but on a much larger scale, across entire disk drives.

	=== Memory Pools ===		=== Memory Pools ===

Msw: /* A pure paging system */

2022-06-15T03:37:44Z

A pure paging system

← Older revision		Revision as of 05:37, 15 June 2022
Line 126:		Line 126:
	Processing business applications in a multi-application, multi-user environment involves frequent switching between different tasks. Thanks to its single-level storage, the AS/400 accomplishes this function much more efficiently than most conventional systems. Switching to a new task in the AS/400 is greatly simplified. There is no need to create a separate address space before the execution of a new task can begin (as is done on Unix and Windows systems). AS/400 is designed for very frequent task-switching that characterizes modern commercial business environments. Single-level storage simplifies storage management, and delivers exceptionally good performance, by avoiding the need for swapping of address spaces, and provides a very natural support for data and information sharing across jobs and users.		Processing business applications in a multi-application, multi-user environment involves frequent switching between different tasks. Thanks to its single-level storage, the AS/400 accomplishes this function much more efficiently than most conventional systems. Switching to a new task in the AS/400 is greatly simplified. There is no need to create a separate address space before the execution of a new task can begin (as is done on Unix and Windows systems). AS/400 is designed for very frequent task-switching that characterizes modern commercial business environments. Single-level storage simplifies storage management, and delivers exceptionally good performance, by avoiding the need for swapping of address spaces, and provides a very natural support for data and information sharing across jobs and users.

	==~~A pure~~ paging system==		==AS/400 is truly a paging system==

	IBM learned in the late 1960s and early 1970s that paging I/O is ~~usually~~ faster and less expensive than ordinary file I/O.		IBM learned in the late 1960s and early 1970s that paging I/O is typically faster and less expensive than ordinary disk file I/O.

	All hard ~~disk~~ are mapped into the vast single-level storage (SLS) address space. Paging is done on demand, as applications refer to addresses that are not currently in real main storage (memory). The LIC (or SLIC) Applications simply request contents from addresses and the layer below XPF, the LIC (or SLIC on RISC-based AS/400s) takes care of bringing the data into main storage when a page fault occurs. This means that applications above the MI are not aware of virtual memory or paging, per se.		All AS/400 hard disks (DASD) are mapped into the vast single-level storage (SLS) address space. Paging is done on demand, as applications refer to addresses that are not currently in real main storage (memory). The LIC (or SLIC) Applications simply request contents from addresses and the layer below XPF, the LIC (or SLIC on RISC-based AS/400s) takes care of bringing the data into main storage when a page fault occurs. This means that applications above the MI are not aware of virtual memory or paging, per se.

	This also explains why the AS/400 platform lacks a traditional disk-resident "File System." Since all disks are part of the vast virtual memory space of SLS, everything visible to XPF are objects at a given address, with certain properties. This also permits easy sharing of these objects between requesting processes (or jobs).		This also explains why the AS/400 platform lacks a traditional disk-resident "File System." Since all disks are part of the vast virtual memory space of SLS, everything visible to XPF are objects at a given address, with certain properties. This also permits easy sharing of these objects between requesting processes (or jobs).

	Another advantage of this SLS approach is the ability to do very fast context switches.<ref>According to Frank Soltis in his books ''Inside the AS/400'', and ''Fortress Rochester''.</ref> This is the reason why even older slower IMPI machines with 100 % loaded CPU still provided astonishingly fast interactive response times, when compared with other common platforms of that era.		Another advantage of this SLS approach is the ability to do very fast context switches.<ref>According to Frank Soltis in his books ''Inside the AS/400'', and ''Fortress Rochester''.</ref> This is the reason why even older slower IMPI machines with 100 % loaded CPU still provided astonishingly fast interactive response times, when compared with other common platforms of that era.

			== Database tables in virtual memory ==

			Conceptually, the rows of data in an AS/400 database physical file member (aka. an MI data space) are laid out, one column after another, and one row after another, just like a big array in virtual storage. So, to fetch a given row from any particular database table (or file), one needs only to know the starting address of the first row and the total record length. Multiply the record length times the desired record number, and add that to the base address and you have computed the address of the desired data in virtual memory (SLS). Then it is simply a matter of paging in the desired page(s).

			In reality, it is not quite that simple, but almost. IBM added the specialized MI instructions for database management, journal management, and commitment control, to permit safe concurrent access to and updating of the data in database tables (files) across the entire platform (by many interactive and batch jobs, accessing the same database table at the same time.)

	=== Disk Allocations ===		=== Disk Allocations ===

Msw at 22:46, 14 June 2022

2022-06-14T22:46:18Z

← Older revision		Revision as of 00:46, 15 June 2022
Line 126:		Line 126:
	Processing business applications in a multi-application, multi-user environment involves frequent switching between different tasks. Thanks to its single-level storage, the AS/400 accomplishes this function much more efficiently than most conventional systems. Switching to a new task in the AS/400 is greatly simplified. There is no need to create a separate address space before the execution of a new task can begin (as is done on Unix and Windows systems). AS/400 is designed for very frequent task-switching that characterizes modern commercial business environments. Single-level storage simplifies storage management, and delivers exceptionally good performance, by avoiding the need for swapping of address spaces, and provides a very natural support for data and information sharing across jobs and users.		Processing business applications in a multi-application, multi-user environment involves frequent switching between different tasks. Thanks to its single-level storage, the AS/400 accomplishes this function much more efficiently than most conventional systems. Switching to a new task in the AS/400 is greatly simplified. There is no need to create a separate address space before the execution of a new task can begin (as is done on Unix and Windows systems). AS/400 is designed for very frequent task-switching that characterizes modern commercial business environments. Single-level storage simplifies storage management, and delivers exceptionally good performance, by avoiding the need for swapping of address spaces, and provides a very natural support for data and information sharing across jobs and users.

	~~Putting It All Together~~		==A pure paging system==

	~~A hard disk may be seen as a giant memory area mapped into~~ the ~~address space of XPF components. Swapping~~ and ~~Paging~~ is ~~not done on the application layer as most conventional systems do, but on the address layer. Applications simply request contents from addresses~~ and ~~the layer below XPF, the LIC (or SLIC on RISC-based AS~~/~~400s) takes care of bringing the data into RAM, should a page fault occur. Thus, page faults can occur for data, as well as for executable code~~.		IBM learned in the late 1960s and early 1970s that paging I/O is usually faster and less expensive than ordinary file I/O.

	~~This concept also explains why the AS/400 platform lacks a conventional File System on~~ disk~~. Since all disks~~ are ~~essentially memory~~ mapped into ~~virtual memory~~ space, ~~everything visible is just an object at an address with certain properties~~. ~~This allows to easily share these objects between requesting processes~~ (or ~~jobs~~).		All hard disk are mapped into the vast single-level storage (SLS) address space. Paging is done on demand, as applications refer to addresses that are not currently in real main storage (memory). The LIC (or SLIC) Applications simply request contents from addresses and the layer below XPF, the LIC (or SLIC on RISC-based AS/400s) takes care of bringing the data into main storage when a page fault occurs. This means that applications above the MI are not aware of virtual memory or paging, per se.

	~~One~~ advantage of this approach is the ability to do very fast context switches ~~(if no or only a few page faults occur)~~.<ref>According to Frank Soltis in his ~~Books~~ ''Inside the AS/400'', and ''Fortress Rochester''.</ref> This is the reason why even older machines with 100 % loaded CPU still ~~have an~~ astonishingly fast interactive response ~~time~~, when compared with common platforms of that era~~. If disk accesses are necessary for a context switch to take place, there's no notable speed difference to common platforms, though~~.		This also explains why the AS/400 platform lacks a traditional disk-resident "File System." Since all disks are part of the vast virtual memory space of SLS, everything visible to XPF are objects at a given address, with certain properties. This also permits easy sharing of these objects between requesting processes (or jobs).

			Another advantage of this SLS approach is the ability to do very fast context switches.<ref>According to Frank Soltis in his books ''Inside the AS/400'', and ''Fortress Rochester''.</ref> This is the reason why even older slower IMPI machines with 100 % loaded CPU still provided astonishingly fast interactive response times, when compared with other common platforms of that era.

	=== Disk Allocations ===		=== Disk Allocations ===