Try-AS/400 - User contributions [en]

Tape device related system reference codes

2026-10-24T20:16:42Z

PoC: Added codes seen with tape drives, too

Older hardware might suffer from '''tape device related''' errors more frequently. Interestingly, detailed information is hard to find. This is because '''system reference codes''' often refer to a certain piece of hardware (Feature Code) or FC and the actual error code. Because IBM over time released a multitude of tape devices, the possible combinations are plenty. This means, querying an internet search engine most likely will not turn up the desired results.

The following table lists the documented second half of SRCs<ref>System Reference Codes</ref> for the tape device '''63A0''', which is originally assigned to IBM LTO cartridge tape drives, but is very likely also assigned to similar, generic cartridge drives:
* Generic HP LTO drives,
* Quantum DLT drives,
* HP DDS DAT drives,
* possibly more.

Interestingly, the subsequent drive itself is shown as type 6382, the SLR/QIC 4 GiB drive.

{|class="wikitable"
!SRC
!Description
|-
|3010
|Disk device returned wrong/unexpected response to IOP
|-
|3100
|Tape/CD or disk bus interface error occurred
|-
|9020
|I/O processor detected a SCSI bus configuration error
|-
|9100
|Interface error detected by I/O processor or by tape unit
|-
|9101
|Fibre Channel interface error detected
|-
|9102
|Gateway device<ref>This is related to IBM SAN.</ref> detected a SCSI interface error
|-
|9200
|I/O processor addressed the tape unit; no response
|-
|9201
|Tape unit command timeout
|-
|9202
|Tape unit failed after Licensed Internal Code was loaded
|-
|9210
|Illegal or unsupported tape unit response
|-
|9211
|Gateway device detected a bus protocol error
|-
|9300
|Tape unit failure
|-
|9301
|Tape device failure, redundancy lost
|-
|9302
|Tape device failure or media error
|-
|9303
|Gateway device failure
|-
|9310
|Licensed Internal Code for the tape unit is not correct
|-
|9320
|Tape device Licensed Internal Code failure
|-
|9321
|Gateway device Licensed Internal Code error
|-
|9350
|Tape unit detected a read or write error on tape medium
|-
|9351
|Tape with excessive error rate was mounted in tape device
|-
|9355
|The data format is incorrect; the tape cannot be read
|-
|9500
|I/O processor Licensed Internal Code error
|-
|9800 - 9803
|I/O processor successfully recovered from temporary error
|-
|9810
|Problem analysis has determined a part should be replaced
|-
|9899
|Problem analysis completed, the problem has been corrected
|-
|9900
|Licensed Internal Code for tape unit was not upgraded
|-
|FFF6
|Tape volume statistics logged (no action required)
|}

== See also ==
* [[Tape Drives on old AS/400]]
* [[Disk device related system reference codes]]

== Weblinks ==
* [https://www.ibm.com/resources/publications/OutputPubsDetails?PubID=SY44591501 iSeries 270, 800, 810, 820, 825, 830, 840, 870, 890, SB2, and SB3 Analyze Hardware Problems (System Reference Codes)], SY44-5915-01

== Footnotes ==
<references />

[[Category: Hardware Documentation‏‎]]
[[Category: System Administration]]
[[Category: System Internals‏‎]]

Performance adjustment for Solid State Memory

2026-10-15T09:18:17Z

PoC: /* Thread multiplier */ Better formatting

OS/400 '''Performance adjustment for Solid State Memory''' sheds some light on how to tune a system in regard to the almost zero latency for this type of secondary storage.

__TOC__

OS/400 is an ''paged virtual memory'' platform. There's no direct ''open a file and read the content into RAM'' system function. All data between secondary and primary storage (historically disk, and RAM) flows through the [[wikipedia:Memory paging|paging code]].

Today, disks are largely replaced with solid state, '''[[wikipedia:Flash memory|flash based memory]]'''. It has no moving mechanical parts, eliminates the accompanying access latency, generates no noise, draws less power, generates less heat, and often uses less physical space. Older AS/400 systems can benefit from the [[ZuluSCSI]] parallel SCSI disk emulator.

OS/400 features a so called '''performance adjustment''' function, which automatically splits and shifts available memory around between memory pools according to the current workload, the goal is to minimize paging activity. The default threshold values when, and how much memory is moved around are based on the relatively high latency of rotating disk drives. One particular data point is the ''faulting rate'', essentially how quickly the system tries to bring in data from secondary storage (disk) into primary storage (RAM) for processing. The higher the faulting rate, the more aggressive memory is moved between pools.

<blockquote>'''Note:''' Despite the word ''fault'' seemingly indicating a fatal condition, it isn't. A [[wikipedia:Page fault|page fault]] is a mere indicator that a requested memory location isn't in main storage and a different code path has to be taken to bring it into main storage before processing can commence. Also, a single page fault can result in multiple memory pages being copied into main storage at once.</blockquote>

Solid state memory allows very high paging rates, impossible with spinning disk drives, but without introducing excessive latency. The performance adjust doesn't base adjustment calculations on latency, but on faulting rate. On a system with much disk activity, this can lead to memory starvation of less active pools, and frequent invalidation of in-memory cached data due to quick reassignments of memory.

== Work with Shared Pools ==
The <code>wrkshrpool</code> command allows to adjust threshold values for the performance adjuster by pressing <code>F11</code>. You'll be presented with a table akin to the following. This table shows default values (for V4R5):
{|class="wikitable"
!colspan="2"| 
!colspan="2"|Size (%)
!colspan="3"|Faults/Second
|-
!Pool
!Priority
!Minimum
!Maximum
!Minimum
!Thread
!Maximum
|-
|*MACHINE
|align="right"|1
|align="right"|~25<ref>This value is actually calculated by the system.</ref>
|align="right"|100
|align="right"|10
|align="right"|0
|align="right"|10
|-
|*BASE
|align="right"|1
|align="right"|4.99
|align="right"|100
|align="right"|5
|align="right"|0.5
|align="right"|2000
|-
|*INTERACT
|align="right"|2
|align="right"|5
|align="right"|100
|align="right"|10
|align="right"|2
|align="right"|100
|-
|*SPOOL
|align="right"|2
|align="right"|1
|align="right"|100
|align="right"|5
|align="right"|1
|align="right"|100
|}

A pool's ''priority'' is a relative number from 1 to 14. Lower numbers mean higher priority for pools to be served with additional memory, while higher numbered pools are stripped from excess memory earlier.

Some explanation to the meaning of the ''Faults/Second'' values:
* '''Minimum''': If a pool's faulting rate drops below this value, the adjuster views the pool as over-allocated and will begin to strip memory away from it to feed other pools.
* '''Thread''': A multiplier per (active) thread.
* '''Maximum''': If the pool's faulting rate exceeds this value, the adjuster considers the pool starved and starts aggressively moving memory into it from other pools.

=== Thread multiplier ===
Explanation by example: If one user is running an application in the *INTERACT pool and causing 50 faults/second, that single user is experiencing a performance bottleneck. Contrary, if 100 people are using *INTERACT simultaneously and causing the same 50 faults/second, that means each user is only experiencing 0.5 faults/second. No bottleneck.

The system calculates a ''Dynamic Acceptable Fault Target Threshold = Minimum + (Thread Multiplier × Active Threads)''. If that value exceeds the absolute Maximum value, the latter is considered. Let's take an example of ''multiplier = 2''.

==== Scenario A ====
The system is quiet (5 active threads) 
50 + (2 × 5) = 60 faults/s 
Because only 5 threads are active, the baseline is 60 faults/s. If overall pool activity exceeds 60 faults/s, adjustment will kick in.

==== Scenario B ====
Peak hours (200 active threads) 
50 + (2 × 200) = 450 faults/s 
Now 200 threads are actively sharing the pool, and adjustment scales its tolerance up to 450 faults/sec before it considers the pool "starved" enough to warrant moving memory from elsewhere.

==== Scenario C ====
Extreme burst (600 active threads) 
50 + (2 × 600) = 1250 faults/s 
Because the absolute Maximum is capped at 1000, the math is clipped. The threshold stops scaling and locks firmly at 1000 faults/s.

=== Recommended adjustments ===
Values printed in ''bold'' are changed (non-default) values.

<blockquote>'''Note:''' These values are intended for small scale, or hobbyist systems. If these values hold up for heavy usage has not been established. Expect these values to change over time when additional experience has been gained.</blockquote>

{|class="wikitable"
!colspan="2"| 
!colspan="2"|Size (%)
!colspan="3"|Faults/Second
|-
!Pool
!Priority
!Minimum
!Maximum
!Minimum
!Thread
!Maximum
|-
|*MACHINE
|align="right"|1
|align="right"|*DFT<ref>A literal <tt>*DFT</tt> isn't actually printed but can be used to reset to the default value if it has been changed prior.</ref>
|align="right"|'''50'''
|align="right"|'''100'''
|align="right"|0
|align="right"|'''100'''
|-
|*BASE
|align="right"|1
|align="right"|4.99
|align="right"|100
|align="right"|'''25'''
|align="right"|'''5'''
|align="right"|'''2000'''
|-
|*INTERACT
|align="right"|2
|align="right"|5
|align="right"|'''25'''
|align="right"|'''50'''
|align="right"|'''10'''
|align="right"|'''1000'''
|-
|*SPOOL
|align="right"|'''3'''
|align="right"|1
|align="right"|'''10'''
|align="right"|'''25'''
|align="right"|'''5'''
|align="right"|'''1000'''
|}

The primary goals behind the suggested values are:
* Establish hard ''Size %'' limits to prevent pool starvation.
* Allow for much higher faulting rates (''Faults/Second'') before taking action.
* Using higher scaling values still considers dynamic adjustment up to the raised ''Acceptable Fault Target Threshold'' values, and keeps the basic adjustment logic active.

== See also ==
* [[Post-Install Optimizations]]

== Footnotes ==
<references />

[[Category:Basic Knowledge]]
[[Category:Software Configuration Guide]]
[[Category:System Administration]]

UNIX-User's Cheater Table

2026-10-11T21:26:17Z

PoC: Moved to correct column

This table lists commands available in the ''CL-Environment'', the classical OS/400-Shell, so to say. These do '''not''' apply to ''QSH'' or ''PASE'', that are UNIX-like environments within OS/400.

{|class="wikitable"
!UNIX Command
!OS/400 Equivalent
!Remarks
|-
|colspan="3"|'''Files and File System'''
|-
|valign="top"|<code>cat</code>
|valign="top"|<code>cpyf</code>
|valign="top"|Since OS/400 has no concept of stdin/stdout, these functions of cat don't apply here.
|-
|valign="top"|<code>cd</code>
|valign="top"|<code>chgcurlib</code>
|valign="top"| 
|-
|valign="top"|<code>chmod</code>
|valign="top"|<code>chgaut</code>, <code>grtobjaut</code>, <code>rvkobjaut</code>
|valign="top"| 
|-
|valign="top"|<code>chown</code>, <code>chgrp</code>
|valign="top"|<code>chgobjown</code>, <code>chgobjpgp</code>
|valign="top"| 
|-
|valign="top"|<code>cp</code>
|valign="top"|<code>crtdupobj</code>
|valign="top"| 
|-
|valign="top"|<code>dump</code>, <code>tar c</code>
|valign="top"|<code>sav(lib|obj| )</code>
|valign="top"| 
|-
|valign="top"|<code>ls</code>
|valign="top"|<code>dspobjaut</code>, <code>wrklib</code>, <code>wrkobj</code>
|valign="top"|Shows a scrollable list of selected objects, helps in modifying access rights.
|-
|valign="top"|<code>mv</code>
|valign="top"|<code>rnmobj</code> <code>movobj</code>
|valign="top"| 
|-
|valign="top"|<code>restore</code>, <code>tar [x|t]</code>
|valign="top"|<code>rst(lib|obj| )</code>, <code>dspsavf</code>, <code>dsptap</code>
|valign="top"| 
|-
|valign="top"|<code>test -f</code>
|valign="top"|<code>chkobj</code> <code>chkifsobj</code>
|valign="top"| 
|-
|valign="top"|<code>vi</code>
|valign="top"|<code>strseu</code> for source physical files, <code>edtf</code> for stream files, <code>upddta</code> for database files.
|valign="top"|See [[Filesystems and Files on the AS/400]] for details. See [[IBM HTTP-Server for AS/400 Configuration]] for specialised command regarding web server config.
|-
|colspan="3"|'''Memory and Processes'''
|-
|valign="top"|<code>free</code>
|valign="top"|<code>wrkshrpool</code>
|valign="top"|This is for displaying the amount of built-in RAM.
|-
|valign="top"|<code>crontab -e</code> <code>at</code> (scheduler)
|valign="top"|<code>wrkjobscde</code> <code>sbmjob</code> <code>wrkjobq qbatch</code>
|valign="top"| 
|-
|valign="top"|<code>ps aux</code>, <code>ps -edf</code>, <code>top</code>
|valign="top"|<code>wrkactjob</code>, <code>wrksysact</code>
|valign="top"| 
|-
|colspan="3"|'''Disk and I/O'''
|-
|valign="top"|<code>df</code>
|valign="top"|<code>strsst</code>
|valign="top"|Access to precise disk space stats is available within ''system service tools'' only.
|-
|valign="top"|<code>fsck</code>
|valign="top"|<code>rclstg</code>
|valign="top"|System needs to be in restricted mode.
|-
|valign="top"|<code>iostat -x</code>
|valign="top"|<code>wrkdsksts</code>
|valign="top"| 
|-
|valign="top"|<code>vmstat</code>
|valign="top"|<code>dspsyssts</code>
|valign="top"|Choose view option ''3'' after pressing <code>F19</code>.
|-
|colspan="3"|'''Networking'''
|-
|valign="top"|<code>ping</code>
|valign="top"|<code>ping</code>, <code>aping</code>
|valign="top"|Surprise, command has same name! The latter is for SNA APPN.
|-
|valign="top"|<code>netstat</code>
|valign="top"|<code>netstat</code>, <code>wrkappnsts</code>
|valign="top"|Surprise, command has same name! The latter is for SNA APPN.
|-
|colspan="3"|'''Development'''
|-
|valign="top"|<code>cc</code>
|valign="top"|<code>crtcmod</code>
|valign="top"|Create Object File from C-Source.
|-
|valign="top"|<code>ld</code>
|valign="top"|<code>crtpgm</code>, <code>crtsrvpgm</code>
|valign="top"|Create runnable Program from Object File(s), create Service Program ("Shared Library") from Object File(s).
|-
|valign="top"|<code>make</code>
|valign="top"| 
|valign="top"|There is a crude port of ''make'' in the QUSRTOOLS library called [[Setting up TMKMAKE|TMKMAKE]]. See ''QUSRTOOLS/QATTINFO.TMKINFO'' for details.<ref>See also [https://www.mcpressonline.com/programming-other/general/programming-with-make-on-the-as400-part-i Programming with Make on the AS/400, Part I], and [https://www.mcpressonline.com/programming-other/general/programming-with-make-on-the-as400-part-2 Programming with Make on the AS/400, Part 2] on McPress Online.</ref>
|-
|valign="top"|<code>configure</code>
|valign="top"| 
|valign="top"|No equivalent to GNU autoconf. Possible workaround: Manually tailored, static, universal ''config.h'' for each OS-Release (Compiler Version) based on existing documentation and/or manual tests.
|-
|valign="top"|<code>diff</code>
|valign="top"|<code>cmppfm</code>
|valign="top"| 
|-
|valign="top"|<code>patch</code>
|valign="top"|<code>mrgsrc</code>
|valign="top"| 
|-
|colspan="3"|'''Other Topics'''
|-
|valign="top"|<code>lpq</code>
|valign="top"|<code>wrkoutq</code>
|valign="top"|Displays all configured printer queues and count of entries.
|-
|valign="top"|<code>mailx</code>
|valign="top"|<code>dspmsg</code>, <code>snddst</code>
|valign="top"|Cron and at send mail if there was output. OS/400 sends ''messages'' and generates printer output (spooled file). Sending (SMTP) mail from the command line utilises a completely different facility.
|-
|valign="top"|<code>mt</code>
|valign="top"|<code>dsptap</code>, <code>chktap</code>
|valign="top"| 
|-
|valign="top"|<code>mysql</code>, <code>isql</code>
|valign="top"|<code>strsql</code>
|valign="top"|Not limited to ''mysql'', but more like a placeholder for any command line client accessing a database for entering SQL queries directly.
|-
|valign="top"|<code>whoami</code>
|valign="top"|<code>dspjob</code>
|valign="top"| 
|}

The table will be expanded over time.

== See also ==
* [[Basic Commands]]

== Footnotes ==
<references/>

[[Category: Basic Knowledge‏]]

Start TCP/IP at IPL

2026-10-06T19:28:04Z

PoC: A new V4R5 install revealed that the SBS entry is required with V4R5, too.

To '''Start TCP/IP at IPL''', you have two options, you need to add a pre-start job entry to the appropriate subsystem description.

For V3, there is no appropriate job description for adding the entry, so it must be created prior.
crtjobd jobd(qgpl/qtocstrtcp) jobq(qsys/qsysnomax) TEXT('ADDAJE QSYSWRK to Start TCP/IP at IPL') user(qpgmr) rtgdta('runpty25') rqsdta('qsys/strtcp') log(2 0 *seclvl) jobmsgqmx(*sysval) jobmsgqfl(*wrap)

For V4, an appropriate job queue must be assigned to the already existing job description:
chgjobd jobd(qsys/qtocstrtcp) jobq(qsys/qsysnomax)

Next, fix authorities. This applies to all releases up to V4R4.
chgobjown obj(qtocstrtcp) objtype(*jobd) newown(qsys)
grtobjaut obj(qtocstrtcp) objtype(*jobd) user(qpgmr) aut(*use)
rvkobjaut obj(qtocstrtcp) objtype(*jobd) user(*public) aut(*all)

Finally, add the SBS entry. This also applies to all releases.
addaje sbsd(qsyswrk) job(struptcpip) jobd(*libl/qtocstrtcp)

[[Category: System Administration‏‎]]

Post-Install Optimizations

2026-10-06T13:03:32Z

PoC: /* See also */ +link

OS/400 provides a lot of default values for variables (affecting the run-time environment) and program options. Some of these make sense, some of them are kept consistent with earlier versions of the OS because of compatibility reasons by IBM.

Some of these recommendations might not be appropriate for you by various reasons. Don't apply blindly. Know what you do, use the online help to retrieve background information on the topic in question.

The findings below are based on V4R5 with annotated exceptions for newer releases.

== Housekeeping ==
These are settings and scheduled jobs to keep your system uncluttered.

=== Change unneeded programs to not run ===
We most likely don't need to run ''lpd'' and ''smtpd'' to run per default.
CHGLPDA AUTOSTART(*NO)
CHGSMTPA AUTOSTART(*NO)

You can easily check all settings at once by using <code>UPDDTA QUSRSYS/QATOCSTART</code>. These are not needed in general.
* *DIRSRV
* *NETSVR
* *SLP

Depending on OS version, not all entries may be available.

=== Change uninstalled programs to not run ===
If you did not install the Ultimedia package, you can remove the pre started job from the QSYSWRK subsystem description to make it not generate an error message at IPL time.
RMVPJE SBSD(QSYSWRK) PGM(QUMEDIA/QUMBPJTC)

If you did not install the Directory Services package (aka LDAP), you can remove the auto started jobs from the QSYSWRK subsystem description to make them not generate an error message at IPL time.
RMVAJE SBSD(QSYSWRK) JOB(QGLDPUBA)
RMVAJE SBSD(QSYSWRK) JOB(QGLDPUBE)

Both is valid and tested for V4R5. Note that newer releases moved the background jobs to the base OS so there is no error message when starting them. I have not tested if they're required to run, though.

If you did not install the performance tools, you don't need trying to start the performance data collector:
RMVAJE SBSD(QCTL) JOB(QPFRCOL)

I can't remember if the latter is valid for V4R5. It's valid for V3R2, though.

=== Cleanup unneeded stuff ===
These objects come by default at OS install time, are not needed to my knowledge, and thus can be safely deleted:
DLTOUTQ OUTQ(QDKT)
DLTOUTQ OUTQ(QPFROUTQ)
DLTOUTQ OUTQ(QPRINTS)
DLTF FILE(QPRINTS)
DLTOUTQ OUTQ(QPRINT2)
DLTF FILE(QPRINT2)
DLTOUTQ OUTQ(QTPPPOUTQ)
DLTDEVD DEVD(QESPAP)
DLTDEVD DEVD(QIADSP)
DLTDEVD DEVD(QIAPRT)
DLTDEVD DEVD(QQAHOST)
DLTDEVD DEVD(QTIDA)
DLTDEVD DEVD(QTIDA2)
DLTCTLD CTLD(QESCTL)
DLTCTLD CTLD(QTICTL)
DLTLIND LIND(QESLINE)
DLTLIND LIND(QTILINE)

== System Values ==
System values are like environment variables as known from common operating systems. They influence system operation. I recommend the following changes.

=== System Control ===
* Change work environment to separate subsystems for different kind of jobs. This also makes it easy to introduce your own subsystems.
CHGSYSVAL SYSVAL(QCTLSBSD) VALUE('QCTL QSYS')
* Set automatic DST adjustment, and UTC offset. This value is valid for Central Europe (Berlin, Paris, …) '''Note!''' This variable is not available in V4R5. See [[#Weblinks|Weblinks]] below.
CHGSYSVAL SYSVAL(QTIMZON) VALUE('QP0100CET2')
* Adjust time to automatically end disconnected interactive jobs (sessions) to one day.
CHGSYSVAL SYSVAL(QDSCJOBITV) VALUE('1440')

=== (Memory) Allocation ===
* Adjust automatic performance values only at runtime, not at IPL.<ref>If you change the amount of memory for the machine, temporarily adjust the value to '2', make the memory change and then change the value back to '3' — no further IPL needed.</ref> This allows the system to automatically adjust memory allocations and activity levels to minimize paging (disk I/O).
CHGSYSVAL SYSVAL(QPFRADJ) VALUE('3')
* Allow memory pools to self adjust the paging block size depending on jobs running. This is called ''Expert Cache''. You can adjust the maximum active jobs per pool in the <code>WRKSHRPOOL</code> display.<ref>Press <code>F21</code> to switch to view 2 or 3 to have adjustment possibilities.</ref>
CHGSHRPOOL POOL(*BASE) PAGING(*CALC)
CHGSHRPOOL POOL(*INTERACT) PAGING(*CALC)
CHGSHRPOOL POOL(*SPOOL) PAGING(*CALC)
* Reservations for job related data structures at IPL time. See <code>DSPSYSSTS</code> and set to slightly more than the ''Jobs in System'' value to be seen there when the system is working "normal".<ref>Press <code>F21</code> to switch to view 2 or 3 to see the overall job count.</ref>
CHGSYSVAL SYSVAL(QTOTJOB) VALUE(100)
* Reservations for job related data structures at IPL time. See <code>WRKACTJOB</code> and set to slightly more than the ''Active Jobs'' value to be seen there when the system is working "normal".
CHGSYSVAL SYSVAL(QACTJOB) VALUE(95)
* Maximize TCP buffers for maximum performance, especially on faster links.
CHGTCPA TCPRCVBUF(8388608) TCPSNDBUF(8388608)
* Make sure, database tasks can use system resources as needed.
CHGSYSVAL SYSVAL(QQRYDEGREE) VALUE(*OPTIMIZE)
* When interactive jobs require more CPU time than being allowed by default (2 seconds),<ref>This is set in *CLS objects.</ref> to finish a block of processing, allow that memory to be taken from the *BASE pool. Advantage: The QINTER subsystem pool will not be subject to auto adjustment because of jobs which are supposed to run in batch.
CHGSYSVAL SYSVAL(QTSEPOOL) VALUE(*BASE)

=== Message-and-Logging ===
* Allow immediate deletion of problem reports.
CHGSYSVAL SYSVAL(QPRBHLDITV) VALUE(0)
* Do not log software errors. We can't do much about these anyway, seen from a hobbyist viewpoint.
CHGSYSVAL SYSVAL(QSFWERRLOG) VALUE(*NOLOG)
* Maximize Central Syslog (viewable with <code>DSPLOG</code> size to lessen rotation frequency. Depending on OS version only ''VALUE(32767)'' may be valid.
CHGSYSVAL SYSVAL(QHSTLOGSIZ) VALUE(*DAILY)
* Raise allowed unsuccessful sign on tries before taking action.
CHGSYSVAL SYSVAL(QMAXSIGN) VALUE('15')
* Minimize logging for sessions disconnected beause of device errors.
CHGSYSVAL SYSVAL(QDEVRCYACN) VALUE(*ENDJOBNOLIST)

=== Security System Values ===
* Unrestrict automatic creation of system objects triggered by external (network) requests.
CHGSYSVAL SYSVAL(QAUTOVRT) VALUE(*NOMAX)
* Allow restore with all security relevant flags.
CHGSYSVAL SYSVAL(QALWOBJRST) VALUE(*ALL)
* For TCP connections to work, we need encrypted passwords.
CHGDDMTCPA PWDRQD(*ENCRYPTED)
* Allow ''QSYSOPR'' sign-on to all devices.
CHGSYSVAL SYSVAL(QLMTSECOFR) VALUE('0')
* Raise maximum password length to maximum value.<ref>In newer OS versions, an additional variable ''QPWDLVL'' allows even longer passwords.</ref>
CHGSYSVAL SYSVAL(QPWDMAXLEN) VALUE(10)
* Raise minimum passsword length for security reasons.
CHGSYSVAL SYSVAL(QPWDMINLEN) VALUE(8)

=== Misc ===
* PTF install shall be done on unattended IPL time, and don't try to report problems to IBM directly.<ref>Needs prior setup for ''Electronic Customer Support''.</ref>
CHGSRVA PTFINSTYP(*DLYALL) RPTPRBAUTO(*NO)
* Provide European style formatting.
CHGSYSVAL SYSVAL(QCURSYM) VALUE('€')
CHGSYSVAL SYSVAL(QDECFMT) VALUE('J')
CHGSYSVAL SYSVAL(QSRTSEQ) VALUE(*LANGIDUNQ)<ref>This value isn't available with V4R5. You can use ''*LANGIDSHR'' there.</ref>
CHGSYSVAL SYSVAL(QDATFMT) VALUE('DMY')<ref>Default value for 2924 (US English) is MDY.</ref>
* Allow background compiling in PDM as ordinary user, and submitting batch jobs in general.
GRTOBJAUT OBJ(QGPL/QBATCH) OBJTYPE(*JOBD) USER(*PUBLIC) AUT(*USE)
* Tweaking automatic cleanup (like ''logrotate'').
CHGCLNUP ALWCLNUP(*YES) STRTIME('02:22:22') USRMSG(7) SYSMSG(3) SYSPRT(7) SYSLOG(14) CALITM(*KEEP)
* Change general SNA networking attributes. This is one '''long''' line. Take care to get it completely.
CHGNETA JOBACN(*SEARCH) VRTAUTODEV(254) MDMCNTRYID(DE)

=== Charset Conversion ===
In addition, OS/400 has a default value of 65535 for <code>QCCSID</code>. It should be set to a value being dependent on the installed language, to enable automatic translation of data on disk to the display device, and back. For Germany, the correct value is 273, and for US, it's 37. A good hint is to check your 5250 emulator program for possible values.

== IPL Customization ==
With this procedure, the current startup program for the OS can be retrieved for easy customization.
RTVCLSRC PGM(QSTRUP) SRCFILE(QCLSRC)
WRKMBRPDM FILE(QCLSRC) MBR(QSTRUP) MBRTYPE(CLP)
CRTCLPGM PGM(QGPL/QSTRUP)

To activate your changes, run <code>WRKSYSVAL SYSVAL(QSTRUPPGM)</code> and change the values to reflect the new program object in QGPL. '''Note''': On a used system's install, the previous owner might have already done a customized QSTRUP. See <code>DSPSYSVAL QSTRUPPGM</code> which one is the currently set startup program before accidentally overwriting!

Notable use cases for changing <code>QSTRUP</code> would be to make SNA Distribution Services, and TCP/IP (on older releases than V4R5) start at IPL time.

New entries must be located after the ''IF COND'' statement and ''DONE:'' label. Always put a ''MONMSG MSGID(CPF0000)'' after each statement. Failing to do so will not ignore any errors but make the IPL script terminate abnormally in case of an error and possibly leave you with an inaccessible system.

Examples:
* Start TCP/IP:
QSYS/STRTCP
MONMSG MSGID(CPF0000)
<blockquote>'''Note:''' TCP/IP on V4R5 and later is by IBM provided default automatically started with an appropriate autostart entry <code>struptcpip</code> in the <code>qsyswrk</code> subsystem description. No action is necessary in the startup CL!</blockquote>

* Start SNADS:
QSYS/STRSBS SBSD(QSNADS)
MONMSG MSGID(CPF0000)

== Change Program Defaults ==
This establishes different default behavior of some programs which makes life somewhat easier.<ref>Some people highly oppose against changing default values because the default values have been provided for a reason. But then, the <code>CHGCMDDFT</code> also has been provided for a reason.</ref> At least noting down the changed programs and their former values is recommended, for example in <code>QGPL/QTXTSRC.CMDDFT</code>.
<blockquote>'''Note:''' CL applications might run a command with the changed default values, in turn combining (new) defaults and submitted parameters into an invalid combination of parameters which might lead to run-time errors. As far as I'm aware, my proposed changes are compatible with such situations.</blockquote>

* File creation and change defaults:
** Enforce immediate return to program error handling instead of make programs seem to hang (<code>wait…</code>),
** Enforce reusing deleted record space,<ref>If there is no access path defined, sequentially read records are no longer guaranteed to *be in timely order (FIFO)!</ref>
** Remove sizing restrictions,<ref>A runaway process filling the disks to 100 % is not stopped prior!</ref>
** Use a smaller access path size for probably increased performance,
** Allow automatic LF rebuild when running <code>chgpf</code>.
CHGCMDDFT CMD(CRTPF) NEWDFT('SIZE(*NOMAX *N *N) WAITFILE(*IMMED) WAITRCD(*IMMED) REUSEDLT(*YES)')
CHGCMDDFT CMD(CRTSRCPF) NEWDFT('SIZE(*NOMAX *N *N) ACCPTHSIZ(*MAX4GB)')
CHGCMDDFT CMD(CHGPF) NEWDFT('DLTDEPLF(*YES) SIZE(*NOMAX *N *N) WAITFILE(*IMMED) WAITRCD(*IMMED) REUSEDLT(*YES)')
CHGCMDDFT CMD(CRTLF) NEWDFT('WAITFILE(*IMMED) WAITRCD(*IMMED) ACCPTHSIZ(*MAX4GB)')
CHGCMDDFT CMD(CHGLF) NEWDFT('WAITFILE(*IMMED) WAITRCD(*IMMED) ACCPTHSIZ(*MAX4GB)')
* Menus usually go into the library with the application's other objects. Change current library to there, so applications can find their objects.<ref>It might be beneficial to individually use <code>CURLIB(*NOCHG)</code> for higher level menu objects being put into libraries which are part of the default library search list (''*LIBL'') — such as ''QGPL'' — to not needlessly change the default library in a for some users unexpected way.</ref>
CHGCMDDFT CMD(CRTMNU) NEWDFT('CURLIB(*MNULIB)')
* No unnecessary wait for power down. <code>CONFIRM(*NO)</code> can be added for newer releases to suppress prompting.
CHGCMDDFT CMD(PWRDWNSYS) NEWDFT('OPTION(*IMMED) ENDSBSOPT(*NOJOBLOG)')
* Don't waste time displaying a not so very much interesting screen prior to connection.
CHGCMDDFT CMD(STRPASTHR) NEWDFT('PASTHRSCN(*NO)')

Be aware that reinstalls, or applying PTFs can overwrite command objects and thus their changed default values. Also note, hat installing a secondary language on a system also installs a separate set of <code>*cmd</code> objects for that language. You may want to apply the defaults with qualified object names to these, too.

== Regular Cleanup jobs ==
See job comment TEXT for details. These are '''long''' lines. Take care to get it completely.
ADDJOBSCDE JOB(PRGPRB) CMD(DLTPRB STATUS(*CLOSED)) FRQ(*WEEKLY) SCDDATE(*NONE) SCDDAY(*ALL) SCDTIME('13:22:00') MSGQ(*LIBL/QSYSOPR) TEXT('Purge closed and deletable problem entries')
ADDJOBSCDE JOB(RCLTMPSTG) CMD(RCLTMPSTG DAYS(30)) FRQ(*MONTHLY) SCDDATE(*MONTHSTR) SCDDAY(*NONE) SCDTIME('13:24:00') MSGQ(*LIBL/QSYSOPR) TEXT('Reclaim temporary storage')
ADDJOBSCDE JOB(RTVDSKINF) CMD(RTVDSKINF) FRQ(*MONTHLY) SCDDATE(*MONTHSTR) SCDDAY(*NONE) SCDTIME('13:34:00') MSGQ(*LIBL/QSYSOPR) TEXT('Retrieve disk space stats')
ADDJOBSCDE JOB(QPGMRCLR) CMD(CLRMSGQ MSGQ(QPGMR) CLEAR(*KEEPUNANS)) FRQ(*WEEKLY) SCDDATE(*NONE) SCDDAY(*ALL) SCDTIME('07:07:07') RCYACN(*NOSBM) MSGQ(*NONE) TEXT('Delete uninteresting messages')

== PTF handling ==
To save space on disk and backup media, you may want to consider applying all PTFs permanently. You cannot remove them afterwards, but that largely doesn't really matter for older and hobbyist systems.

From a console, first run an `ENDSYS (*IMMED)` to get the system into restricted, state. Then run
APYPTF LICPGM(*ALL) SELECT(*ALL) APY(*PERM) DELAYED(*YES) IPLAPY(*YES)

This will apply all PTFs permanently upon next normal IPL. Note you should IPL from the A-side to allow changes to the B side being made.

A final IPL to the B side gets you the fully PTF'd system.

== Re-Enable InfoSeeker ==
Only necessary for newer V4R4 and newer. If the command isn't known, don't bother: Then your release is so new that it's gone entirely.

See also: [[Reviving InfoSeeker]]

CRTDTAARA DTAARA(QUSRSYS/QBMGINFSKR) TYPE(*CHAR) LEN(8)<ref>Works in V4R5. The <code>STRINFSKR</code> command is not included anymore in IBM i 7.1, and probably earlier releases.</ref>

== Additional Steps tested with V7R2 ==
After trying to enter SST, one gets the message that the password has expired. But the password cannot be changed. Re-IPL '''in manual mode''', do not IPL but enter DST, and change password as directed.

* Choose ''5. Work with DST environment'' and ''3. Service tools user IDs''.
** Disable the "backdoor" profile ''11111111'',
** ''Change password'' for ''QSECOFR'', ''Set password to expired'' to ''2=No''.
* Press F12 and choose ''6. Service tools security data''.
** Enter 0 into the field ''8. Password expiration interval in days'', 8 into the ''Selection'' field, and press return.
** Enter a high number (like 12) into the field ''9. Maximum sign-on attempts allowed'', 9 into the ''Selection'' field, and press return.
** Enter 0 into the field ''10. Duplicate password control'', 10 into the ''Selection'' field, and press return.

Now exit DST.

You may choose to enter SST, enter 7 for ''Work with system security'', and set ''Allow a service tools user ID with a default and expired password to change its own password'' to ''1=Yes''. Since we changed password expiry to ''never'', this step is entirely optional.

== See also ==
* [[Change Command Defaults for File-Commands]]
* [[How to properly shut down your AS/400]]
* [[Performance adjustment for Solid State Memory]]

== Weblinks ==
* [https://archive.midrange.com/midrange-l/199912/msg01738.html STRINFSKR], Midrange Mailing-List
* [https://github.com/PoC-dev/as400-autodst as400-autodst], GitHub

== Footnotes ==
<references />

[[Category: System Administration]]

Performance adjustment for Solid State Memory

2026-10-06T08:51:39Z

PoC: /* Recommended adjustments */ Better wording

OS/400 '''Performance adjustment for Solid State Memory''' sheds some light on how to tune a system in regard to the almost zero latency for this type of secondary storage.

__TOC__

OS/400 is an ''paged virtual memory'' platform. There's no direct ''open a file and read the content into RAM'' system function. All data between secondary and primary storage (historically disk, and RAM) flows through the [[wikipedia:Memory paging|paging code]].

Today, disks are largely replaced with solid state, '''[[wikipedia:Flash memory|flash based memory]]'''. It has no moving mechanical parts, eliminates the accompanying access latency, generates no noise, draws less power, generates less heat, and often uses less physical space. Older AS/400 systems can benefit from the [[ZuluSCSI]] parallel SCSI disk emulator.

OS/400 features a so called '''performance adjustment''' function, which automatically splits and shifts available memory around between memory pools according to the current workload, the goal is to minimize paging activity. The default threshold values when, and how much memory is moved around are based on the relatively high latency of rotating disk drives. One particular data point is the ''faulting rate'', essentially how quickly the system tries to bring in data from secondary storage (disk) into primary storage (RAM) for processing. The higher the faulting rate, the more aggressive memory is moved between pools.

<blockquote>'''Note:''' Despite the word ''fault'' seemingly indicating a fatal condition, it isn't. A [[wikipedia:Page fault|page fault]] is a mere indicator that a requested memory location isn't in main storage and a different code path has to be taken to bring it into main storage before processing can commence. Also, a single page fault can result in multiple memory pages being copied into main storage at once.</blockquote>

Solid state memory allows very high paging rates, impossible with spinning disk drives, but without introducing excessive latency. The performance adjust doesn't base adjustment calculations on latency, but on faulting rate. On a system with much disk activity, this can lead to memory starvation of less active pools, and frequent invalidation of in-memory cached data due to quick reassignments of memory.

== Work with Shared Pools ==
The <code>wrkshrpool</code> command allows to adjust threshold values for the performance adjuster by pressing <code>F11</code>. You'll be presented with a table akin to the following. This table shows default values (for V4R5):
{|class="wikitable"
!colspan="2"| 
!colspan="2"|Size (%)
!colspan="3"|Faults/Second
|-
!Pool
!Priority
!Minimum
!Maximum
!Minimum
!Thread
!Maximum
|-
|*MACHINE
|align="right"|1
|align="right"|~25<ref>This value is actually calculated by the system.</ref>
|align="right"|100
|align="right"|10
|align="right"|0
|align="right"|10
|-
|*BASE
|align="right"|1
|align="right"|4.99
|align="right"|100
|align="right"|5
|align="right"|0.5
|align="right"|2000
|-
|*INTERACT
|align="right"|2
|align="right"|5
|align="right"|100
|align="right"|10
|align="right"|2
|align="right"|100
|-
|*SPOOL
|align="right"|2
|align="right"|1
|align="right"|100
|align="right"|5
|align="right"|1
|align="right"|100
|}

A pool's ''priority'' is a relative number from 1 to 14. Lower numbers mean higher priority for pools to be served with additional memory, while higher numbered pools are stripped from excess memory earlier.

Some explanation to the meaning of the ''Faults/Second'' values:
* '''Minimum''': If a pool's faulting rate drops below this value, the adjuster views the pool as over-allocated and will begin to strip memory away from it to feed other pools.
* '''Thread''': A multiplier per (active) thread.
* '''Maximum''': If the pool's faulting rate exceeds this value, the adjuster considers the pool starved and starts aggressively moving memory into it from other pools.

=== Thread multiplier ===
Explanation by example: If one user is running an application in the *INTERACT pool and causing 50 faults/second, that single user is experiencing a performance bottleneck. Contrary, if 100 people are using *INTERACT simultaneously and causing the same 50 faults/second, that means each user is only experiencing 0.5 faults/second. No bottleneck.

The system calculates a ''Dynamic Acceptable Fault Target Threshold = Minimum + (Thread Multiplier × Active Threads)''. If that value exceeds the absolute Maximum value, the latter is considered. Let's take an example of ''multiplier = 2''.

* Scenario A: The system is quiet (5 active threads) 
50 + (2 × 5) = 60 faults/s 
Because only 5 threads are active, the baseline is 60 faults/s. If overall pool activity exceeds 60 faults/s, adjustment will kick in.
* Scenario B: Peak hours (200 active threads) 
50 + (2 × 200) = 450 faults/s 
Now 200 threads are actively sharing the pool, and adjustment scales its tolerance up to 450 faults/sec before it considers the pool "starved" enough to warrant moving memory from elsewhere.
* Scenario C: Extreme burst (600 active threads) 
50 + (2 × 600) = 1250 faults/s 
Because the absolute Maximum is capped at 1000, the math is clipped. The threshold stops scaling and locks firmly at 1000 faults/s.

=== Recommended adjustments ===
Values printed in ''bold'' are changed (non-default) values.

<blockquote>'''Note:''' These values are intended for small scale, or hobbyist systems. If these values hold up for heavy usage has not been established. Expect these values to change over time when additional experience has been gained.</blockquote>

{|class="wikitable"
!colspan="2"| 
!colspan="2"|Size (%)
!colspan="3"|Faults/Second
|-
!Pool
!Priority
!Minimum
!Maximum
!Minimum
!Thread
!Maximum
|-
|*MACHINE
|align="right"|1
|align="right"|*DFT<ref>A literal <tt>*DFT</tt> isn't actually printed but can be used to reset to the default value if it has been changed prior.</ref>
|align="right"|'''50'''
|align="right"|'''100'''
|align="right"|0
|align="right"|'''100'''
|-
|*BASE
|align="right"|1
|align="right"|4.99
|align="right"|100
|align="right"|'''25'''
|align="right"|'''5'''
|align="right"|'''2000'''
|-
|*INTERACT
|align="right"|2
|align="right"|5
|align="right"|'''25'''
|align="right"|'''50'''
|align="right"|'''10'''
|align="right"|'''1000'''
|-
|*SPOOL
|align="right"|'''3'''
|align="right"|1
|align="right"|'''10'''
|align="right"|'''25'''
|align="right"|'''5'''
|align="right"|'''1000'''
|}

The primary goals behind the suggested values are:
* Establish hard ''Size %'' limits to prevent pool starvation.
* Allow for much higher faulting rates (''Faults/Second'') before taking action.
* Using higher scaling values still considers dynamic adjustment up to the raised ''Acceptable Fault Target Threshold'' values, and keeps the basic adjustment logic active.

== See also ==
* [[Post-Install Optimizations]]

== Footnotes ==
<references />

[[Category:Basic Knowledge]]
[[Category:Software Configuration Guide]]
[[Category:System Administration]]

Performance adjustment for Solid State Memory

2026-10-06T08:43:50Z

PoC: /* Work with Shared Pools */ Better wording

OS/400 '''Performance adjustment for Solid State Memory''' sheds some light on how to tune a system in regard to the almost zero latency for this type of secondary storage.

__TOC__

OS/400 is an ''paged virtual memory'' platform. There's no direct ''open a file and read the content into RAM'' system function. All data between secondary and primary storage (historically disk, and RAM) flows through the [[wikipedia:Memory paging|paging code]].

Today, disks are largely replaced with solid state, '''[[wikipedia:Flash memory|flash based memory]]'''. It has no moving mechanical parts, eliminates the accompanying access latency, generates no noise, draws less power, generates less heat, and often uses less physical space. Older AS/400 systems can benefit from the [[ZuluSCSI]] parallel SCSI disk emulator.

OS/400 features a so called '''performance adjustment''' function, which automatically splits and shifts available memory around between memory pools according to the current workload, the goal is to minimize paging activity. The default threshold values when, and how much memory is moved around are based on the relatively high latency of rotating disk drives. One particular data point is the ''faulting rate'', essentially how quickly the system tries to bring in data from secondary storage (disk) into primary storage (RAM) for processing. The higher the faulting rate, the more aggressive memory is moved between pools.

<blockquote>'''Note:''' Despite the word ''fault'' seemingly indicating a fatal condition, it isn't. A [[wikipedia:Page fault|page fault]] is a mere indicator that a requested memory location isn't in main storage and a different code path has to be taken to bring it into main storage before processing can commence. Also, a single page fault can result in multiple memory pages being copied into main storage at once.</blockquote>

Solid state memory allows very high paging rates, impossible with spinning disk drives, but without introducing excessive latency. The performance adjust doesn't base adjustment calculations on latency, but on faulting rate. On a system with much disk activity, this can lead to memory starvation of less active pools, and frequent invalidation of in-memory cached data due to quick reassignments of memory.

== Work with Shared Pools ==
The <code>wrkshrpool</code> command allows to adjust threshold values for the performance adjuster by pressing <code>F11</code>. You'll be presented with a table akin to the following. This table shows default values (for V4R5):
{|class="wikitable"
!colspan="2"| 
!colspan="2"|Size (%)
!colspan="3"|Faults/Second
|-
!Pool
!Priority
!Minimum
!Maximum
!Minimum
!Thread
!Maximum
|-
|*MACHINE
|align="right"|1
|align="right"|~25<ref>This value is actually calculated by the system.</ref>
|align="right"|100
|align="right"|10
|align="right"|0
|align="right"|10
|-
|*BASE
|align="right"|1
|align="right"|4.99
|align="right"|100
|align="right"|5
|align="right"|0.5
|align="right"|2000
|-
|*INTERACT
|align="right"|2
|align="right"|5
|align="right"|100
|align="right"|10
|align="right"|2
|align="right"|100
|-
|*SPOOL
|align="right"|2
|align="right"|1
|align="right"|100
|align="right"|5
|align="right"|1
|align="right"|100
|}

A pool's ''priority'' is a relative number from 1 to 14. Lower numbers mean higher priority for pools to be served with additional memory, while higher numbered pools are stripped from excess memory earlier.

Some explanation to the meaning of the ''Faults/Second'' values:
* '''Minimum''': If a pool's faulting rate drops below this value, the adjuster views the pool as over-allocated and will begin to strip memory away from it to feed other pools.
* '''Thread''': A multiplier per (active) thread.
* '''Maximum''': If the pool's faulting rate exceeds this value, the adjuster considers the pool starved and starts aggressively moving memory into it from other pools.

=== Thread multiplier ===
Explanation by example: If one user is running an application in the *INTERACT pool and causing 50 faults/second, that single user is experiencing a performance bottleneck. Contrary, if 100 people are using *INTERACT simultaneously and causing the same 50 faults/second, that means each user is only experiencing 0.5 faults/second. No bottleneck.

The system calculates a ''Dynamic Acceptable Fault Target Threshold = Minimum + (Thread Multiplier × Active Threads)''. If that value exceeds the absolute Maximum value, the latter is considered. Let's take an example of ''multiplier = 2''.

* Scenario A: The system is quiet (5 active threads) 
50 + (2 × 5) = 60 faults/s 
Because only 5 threads are active, the baseline is 60 faults/s. If overall pool activity exceeds 60 faults/s, adjustment will kick in.
* Scenario B: Peak hours (200 active threads) 
50 + (2 × 200) = 450 faults/s 
Now 200 threads are actively sharing the pool, and adjustment scales its tolerance up to 450 faults/sec before it considers the pool "starved" enough to warrant moving memory from elsewhere.
* Scenario C: Extreme burst (600 active threads) 
50 + (2 × 600) = 1250 faults/s 
Because the absolute Maximum is capped at 1000, the math is clipped. The threshold stops scaling and locks firmly at 1000 faults/s.

=== Recommended adjustments ===
Values printed in ''bold'' are changed (non-default) values.

<blockquote>'''Note:''' These values are intended for small scale, or hobbyist systems. If these values hold up for heavy usage has not been established.</blockquote>

{|class="wikitable"
!colspan="2"| 
!colspan="2"|Size (%)
!colspan="3"|Faults/Second
|-
!Pool
!Priority
!Minimum
!Maximum
!Minimum
!Thread
!Maximum
|-
|*MACHINE
|align="right"|1
|align="right"|*DFT<ref>A literal <tt>*DFT</tt> isn't actually printed but can be used to reset to the default value if it has been changed prior.</ref>
|align="right"|'''50'''
|align="right"|'''100'''
|align="right"|0
|align="right"|'''100'''
|-
|*BASE
|align="right"|1
|align="right"|4.99
|align="right"|100
|align="right"|'''25'''
|align="right"|'''5'''
|align="right"|'''2000'''
|-
|*INTERACT
|align="right"|2
|align="right"|5
|align="right"|'''25'''
|align="right"|'''50'''
|align="right"|'''10'''
|align="right"|'''1000'''
|-
|*SPOOL
|align="right"|'''3'''
|align="right"|1
|align="right"|'''10'''
|align="right"|'''25'''
|align="right"|'''5'''
|align="right"|'''1000'''
|}

The primary goals behind the suggested values are:
* Establish hard ''Size %'' limits to prevent pool starvation.
* Allow for much higher faulting rates (''Faults/Second'') before taking action.
* Using higher scaling values still considers dynamic adjustment up to the raised ''Acceptable Fault Target Threshold'' values, and keeps the basic adjustment logic active.

== See also ==
* [[Post-Install Optimizations]]

== Footnotes ==
<references />

[[Category:Basic Knowledge]]
[[Category:Software Configuration Guide]]
[[Category:System Administration]]

Performance adjustment for Solid State Memory

2026-10-06T08:42:50Z

PoC: /* Recommended adjustments */ Footnote

OS/400 '''Performance adjustment for Solid State Memory''' sheds some light on how to tune a system in regard to the almost zero latency for this type of secondary storage.

__TOC__

OS/400 is an ''paged virtual memory'' platform. There's no direct ''open a file and read the content into RAM'' system function. All data between secondary and primary storage (historically disk, and RAM) flows through the [[wikipedia:Memory paging|paging code]].

Today, disks are largely replaced with solid state, '''[[wikipedia:Flash memory|flash based memory]]'''. It has no moving mechanical parts, eliminates the accompanying access latency, generates no noise, draws less power, generates less heat, and often uses less physical space. Older AS/400 systems can benefit from the [[ZuluSCSI]] parallel SCSI disk emulator.

OS/400 features a so called '''performance adjustment''' function, which automatically splits and shifts available memory around between memory pools according to the current workload, the goal is to minimize paging activity. The default threshold values when, and how much memory is moved around are based on the relatively high latency of rotating disk drives. One particular data point is the ''faulting rate'', essentially how quickly the system tries to bring in data from secondary storage (disk) into primary storage (RAM) for processing. The higher the faulting rate, the more aggressive memory is moved between pools.

<blockquote>'''Note:''' Despite the word ''fault'' seemingly indicating a fatal condition, it isn't. A [[wikipedia:Page fault|page fault]] is a mere indicator that a requested memory location isn't in main storage and a different code path has to be taken to bring it into main storage before processing can commence. Also, a single page fault can result in multiple memory pages being copied into main storage at once.</blockquote>

Solid state memory allows very high paging rates, impossible with spinning disk drives, but without introducing excessive latency. The performance adjust doesn't base adjustment calculations on latency, but on faulting rate. On a system with much disk activity, this can lead to memory starvation of less active pools, and frequent invalidation of in-memory cached data due to quick reassignments of memory.

== Work with Shared Pools ==
The <code>wrkshrpool</code> command allows to adjust threshold values for the performance adjuster by pressing <code>F11</code>. You'll be presented with a table akin to the following. This table shows default values (for V4R5):
{|class="wikitable"
!colspan="2"| 
!colspan="2"|Size (%)
!colspan="3"|Faults/Second
|-
!Pool
!Priority
!Minimum
!Maximum
!Minimum
!Thread
!Maximum
|-
|*MACHINE
|align="right"|1
|align="right"|~25<ref>This value is calculated by the system.</ref>
|align="right"|100
|align="right"|10
|align="right"|0
|align="right"|10
|-
|*BASE
|align="right"|1
|align="right"|4.99
|align="right"|100
|align="right"|5
|align="right"|0.5
|align="right"|2000
|-
|*INTERACT
|align="right"|2
|align="right"|5
|align="right"|100
|align="right"|10
|align="right"|2
|align="right"|100
|-
|*SPOOL
|align="right"|2
|align="right"|1
|align="right"|100
|align="right"|5
|align="right"|1
|align="right"|100
|}

A pool's ''priority'' is a relative number from 1 to 14. Lower numbers mean higher priority for pools to be served with additional memory, while higher numbered pools are stripped from excess memory earlier.

Some explanation to the meaning of the ''Faults/Second'' values:
* '''Minimum''': If a pool's faulting rate drops below this value, the adjuster views the pool as over-allocated and will begin to strip memory away from it to feed other pools.
* '''Thread''': A multiplier per (active) thread.
* '''Maximum''': If the pool's faulting rate exceeds this value, the adjuster considers the pool starved and starts aggressively moving memory into it from other pools.

=== Thread multiplier ===
Explanation by example: If one user is running an application in the *INTERACT pool and causing 50 faults/second, that single user is experiencing a performance bottleneck. Contrary, if 100 people are using *INTERACT simultaneously and causing the same 50 faults/second, that means each user is only experiencing 0.5 faults/second. No bottleneck.

The system calculates a ''Dynamic Acceptable Fault Target Threshold = Minimum + (Thread Multiplier × Active Threads)''. If that value exceeds the absolute Maximum value, the latter is considered. Let's take an example of ''multiplier = 2''.

* Scenario A: The system is quiet (5 active threads) 
50 + (2 × 5) = 60 faults/s 
Because only 5 threads are active, the baseline is 60 faults/s. If overall pool activity exceeds 60 faults/s, adjustment will kick in.
* Scenario B: Peak hours (200 active threads) 
50 + (2 × 200) = 450 faults/s 
Now 200 threads are actively sharing the pool, and adjustment scales its tolerance up to 450 faults/sec before it considers the pool "starved" enough to warrant moving memory from elsewhere.
* Scenario C: Extreme burst (600 active threads) 
50 + (2 × 600) = 1250 faults/s 
Because the absolute Maximum is capped at 1000, the math is clipped. The threshold stops scaling and locks firmly at 1000 faults/s.

=== Recommended adjustments ===
Values printed in ''bold'' are changed (non-default) values.

<blockquote>'''Note:''' These values are intended for small scale, or hobbyist systems. If these values hold up for heavy usage has not been established.</blockquote>

{|class="wikitable"
!colspan="2"| 
!colspan="2"|Size (%)
!colspan="3"|Faults/Second
|-
!Pool
!Priority
!Minimum
!Maximum
!Minimum
!Thread
!Maximum
|-
|*MACHINE
|align="right"|1
|align="right"|*DFT<ref>A literal <tt>*DFT</tt> isn't actually printed but can be used if the value has been changed prior.</ref>
|align="right"|'''50'''
|align="right"|'''100'''
|align="right"|0
|align="right"|'''100'''
|-
|*BASE
|align="right"|1
|align="right"|4.99
|align="right"|100
|align="right"|'''25'''
|align="right"|'''5'''
|align="right"|'''2000'''
|-
|*INTERACT
|align="right"|2
|align="right"|5
|align="right"|'''25'''
|align="right"|'''50'''
|align="right"|'''10'''
|align="right"|'''1000'''
|-
|*SPOOL
|align="right"|'''3'''
|align="right"|1
|align="right"|'''10'''
|align="right"|'''25'''
|align="right"|'''5'''
|align="right"|'''1000'''
|}

The primary goals behind the suggested values are:
* Establish hard ''Size %'' limits to prevent pool starvation.
* Allow for much higher faulting rates (''Faults/Second'') before taking action.
* Using higher scaling values still considers dynamic adjustment up to the raised ''Acceptable Fault Target Threshold'' values, and keeps the basic adjustment logic active.

== See also ==
* [[Post-Install Optimizations]]

== Footnotes ==
<references />

[[Category:Basic Knowledge]]
[[Category:Software Configuration Guide]]
[[Category:System Administration]]

Performance adjustment for Solid State Memory

2026-10-06T08:39:00Z

PoC: Ready

OS/400 '''Performance adjustment for Solid State Memory''' sheds some light on how to tune a system in regard to the almost zero latency for this type of secondary storage.

__TOC__

OS/400 is an ''paged virtual memory'' platform. There's no direct ''open a file and read the content into RAM'' system function. All data between secondary and primary storage (historically disk, and RAM) flows through the [[wikipedia:Memory paging|paging code]].

Today, disks are largely replaced with solid state, '''[[wikipedia:Flash memory|flash based memory]]'''. It has no moving mechanical parts, eliminates the accompanying access latency, generates no noise, draws less power, generates less heat, and often uses less physical space. Older AS/400 systems can benefit from the [[ZuluSCSI]] parallel SCSI disk emulator.

OS/400 features a so called '''performance adjustment''' function, which automatically splits and shifts available memory around between memory pools according to the current workload, the goal is to minimize paging activity. The default threshold values when, and how much memory is moved around are based on the relatively high latency of rotating disk drives. One particular data point is the ''faulting rate'', essentially how quickly the system tries to bring in data from secondary storage (disk) into primary storage (RAM) for processing. The higher the faulting rate, the more aggressive memory is moved between pools.

<blockquote>'''Note:''' Despite the word ''fault'' seemingly indicating a fatal condition, it isn't. A [[wikipedia:Page fault|page fault]] is a mere indicator that a requested memory location isn't in main storage and a different code path has to be taken to bring it into main storage before processing can commence. Also, a single page fault can result in multiple memory pages being copied into main storage at once.</blockquote>

Solid state memory allows very high paging rates, impossible with spinning disk drives, but without introducing excessive latency. The performance adjust doesn't base adjustment calculations on latency, but on faulting rate. On a system with much disk activity, this can lead to memory starvation of less active pools, and frequent invalidation of in-memory cached data due to quick reassignments of memory.

== Work with Shared Pools ==
The <code>wrkshrpool</code> command allows to adjust threshold values for the performance adjuster by pressing <code>F11</code>. You'll be presented with a table akin to the following. This table shows default values (for V4R5):
{|class="wikitable"
!colspan="2"| 
!colspan="2"|Size (%)
!colspan="3"|Faults/Second
|-
!Pool
!Priority
!Minimum
!Maximum
!Minimum
!Thread
!Maximum
|-
|*MACHINE
|align="right"|1
|align="right"|~25<ref>This value is calculated by the system.</ref>
|align="right"|100
|align="right"|10
|align="right"|0
|align="right"|10
|-
|*BASE
|align="right"|1
|align="right"|4.99
|align="right"|100
|align="right"|5
|align="right"|0.5
|align="right"|2000
|-
|*INTERACT
|align="right"|2
|align="right"|5
|align="right"|100
|align="right"|10
|align="right"|2
|align="right"|100
|-
|*SPOOL
|align="right"|2
|align="right"|1
|align="right"|100
|align="right"|5
|align="right"|1
|align="right"|100
|}

A pool's ''priority'' is a relative number from 1 to 14. Lower numbers mean higher priority for pools to be served with additional memory, while higher numbered pools are stripped from excess memory earlier.

Some explanation to the meaning of the ''Faults/Second'' values:
* '''Minimum''': If a pool's faulting rate drops below this value, the adjuster views the pool as over-allocated and will begin to strip memory away from it to feed other pools.
* '''Thread''': A multiplier per (active) thread.
* '''Maximum''': If the pool's faulting rate exceeds this value, the adjuster considers the pool starved and starts aggressively moving memory into it from other pools.

=== Thread multiplier ===
Explanation by example: If one user is running an application in the *INTERACT pool and causing 50 faults/second, that single user is experiencing a performance bottleneck. Contrary, if 100 people are using *INTERACT simultaneously and causing the same 50 faults/second, that means each user is only experiencing 0.5 faults/second. No bottleneck.

The system calculates a ''Dynamic Acceptable Fault Target Threshold = Minimum + (Thread Multiplier × Active Threads)''. If that value exceeds the absolute Maximum value, the latter is considered. Let's take an example of ''multiplier = 2''.

* Scenario A: The system is quiet (5 active threads) 
50 + (2 × 5) = 60 faults/s 
Because only 5 threads are active, the baseline is 60 faults/s. If overall pool activity exceeds 60 faults/s, adjustment will kick in.
* Scenario B: Peak hours (200 active threads) 
50 + (2 × 200) = 450 faults/s 
Now 200 threads are actively sharing the pool, and adjustment scales its tolerance up to 450 faults/sec before it considers the pool "starved" enough to warrant moving memory from elsewhere.
* Scenario C: Extreme burst (600 active threads) 
50 + (2 × 600) = 1250 faults/s 
Because the absolute Maximum is capped at 1000, the math is clipped. The threshold stops scaling and locks firmly at 1000 faults/s.

=== Recommended adjustments ===
Values printed in ''bold'' are changed (non-default) values.

<blockquote>'''Note:''' These values are intended for small scale, or hobbyist systems. If these values hold up for heavy usage has not been established.</blockquote>

{|class="wikitable"
!colspan="2"| 
!colspan="2"|Size (%)
!colspan="3"|Faults/Second
|-
!Pool
!Priority
!Minimum
!Maximum
!Minimum
!Thread
!Maximum
|-
|*MACHINE
|align="right"|1
|align="right"|25.49<ref>Use literal <tt>*DFT</tt> to reset to default, if unsure.</ref>
|align="right"|'''50'''
|align="right"|'''100'''
|align="right"|0
|align="right"|'''100'''
|-
|*BASE
|align="right"|1
|align="right"|4.99
|align="right"|100
|align="right"|'''25'''
|align="right"|'''5'''
|align="right"|'''2000'''
|-
|*INTERACT
|align="right"|2
|align="right"|5
|align="right"|'''25'''
|align="right"|'''50'''
|align="right"|'''10'''
|align="right"|'''1000'''
|-
|*SPOOL
|align="right"|'''3'''
|align="right"|1
|align="right"|'''10'''
|align="right"|'''25'''
|align="right"|'''5'''
|align="right"|'''1000'''
|}

The primary goals behind the suggested values are:
* Establish hard ''Size %'' limits to prevent pool starvation.
* Allow for much higher faulting rates (''Faults/Second'') before taking action.
* Using higher scaling values still considers dynamic adjustment up to the raised ''Acceptable Fault Target Threshold'' values, and keeps the basic adjustment logic active.

== See also ==
* [[Post-Install Optimizations]]

== Footnotes ==
<references />

[[Category:Basic Knowledge]]
[[Category:Software Configuration Guide]]
[[Category:System Administration]]

Performance adjustment for Solid State Memory

2026-10-06T08:38:38Z

PoC: /* Recommended adjustments */ Better wording

{{FIXME|Finish article}}
OS/400 '''Performance adjustment for Solid State Memory''' sheds some light on how to tune a system in regard to the almost zero latency for this type of secondary storage.

__TOC__

OS/400 is an ''paged virtual memory'' platform. There's no direct ''open a file and read the content into RAM'' system function. All data between secondary and primary storage (historically disk, and RAM) flows through the [[wikipedia:Memory paging|paging code]].

Today, disks are largely replaced with solid state, '''[[wikipedia:Flash memory|flash based memory]]'''. It has no moving mechanical parts, eliminates the accompanying access latency, generates no noise, draws less power, generates less heat, and often uses less physical space. Older AS/400 systems can benefit from the [[ZuluSCSI]] parallel SCSI disk emulator.

OS/400 features a so called '''performance adjustment''' function, which automatically splits and shifts available memory around between memory pools according to the current workload, the goal is to minimize paging activity. The default threshold values when, and how much memory is moved around are based on the relatively high latency of rotating disk drives. One particular data point is the ''faulting rate'', essentially how quickly the system tries to bring in data from secondary storage (disk) into primary storage (RAM) for processing. The higher the faulting rate, the more aggressive memory is moved between pools.

<blockquote>'''Note:''' Despite the word ''fault'' seemingly indicating a fatal condition, it isn't. A [[wikipedia:Page fault|page fault]] is a mere indicator that a requested memory location isn't in main storage and a different code path has to be taken to bring it into main storage before processing can commence. Also, a single page fault can result in multiple memory pages being copied into main storage at once.</blockquote>

Solid state memory allows very high paging rates, impossible with spinning disk drives, but without introducing excessive latency. The performance adjust doesn't base adjustment calculations on latency, but on faulting rate. On a system with much disk activity, this can lead to memory starvation of less active pools, and frequent invalidation of in-memory cached data due to quick reassignments of memory.

== Work with Shared Pools ==
The <code>wrkshrpool</code> command allows to adjust threshold values for the performance adjuster by pressing <code>F11</code>. You'll be presented with a table akin to the following. This table shows default values (for V4R5):
{|class="wikitable"
!colspan="2"| 
!colspan="2"|Size (%)
!colspan="3"|Faults/Second
|-
!Pool
!Priority
!Minimum
!Maximum
!Minimum
!Thread
!Maximum
|-
|*MACHINE
|align="right"|1
|align="right"|~25<ref>This value is calculated by the system.</ref>
|align="right"|100
|align="right"|10
|align="right"|0
|align="right"|10
|-
|*BASE
|align="right"|1
|align="right"|4.99
|align="right"|100
|align="right"|5
|align="right"|0.5
|align="right"|2000
|-
|*INTERACT
|align="right"|2
|align="right"|5
|align="right"|100
|align="right"|10
|align="right"|2
|align="right"|100
|-
|*SPOOL
|align="right"|2
|align="right"|1
|align="right"|100
|align="right"|5
|align="right"|1
|align="right"|100
|}

A pool's ''priority'' is a relative number from 1 to 14. Lower numbers mean higher priority for pools to be served with additional memory, while higher numbered pools are stripped from excess memory earlier.

Some explanation to the meaning of the ''Faults/Second'' values:
* '''Minimum''': If a pool's faulting rate drops below this value, the adjuster views the pool as over-allocated and will begin to strip memory away from it to feed other pools.
* '''Thread''': A multiplier per (active) thread.
* '''Maximum''': If the pool's faulting rate exceeds this value, the adjuster considers the pool starved and starts aggressively moving memory into it from other pools.

=== Thread multiplier ===
Explanation by example: If one user is running an application in the *INTERACT pool and causing 50 faults/second, that single user is experiencing a performance bottleneck. Contrary, if 100 people are using *INTERACT simultaneously and causing the same 50 faults/second, that means each user is only experiencing 0.5 faults/second. No bottleneck.

The system calculates a ''Dynamic Acceptable Fault Target Threshold = Minimum + (Thread Multiplier × Active Threads)''. If that value exceeds the absolute Maximum value, the latter is considered. Let's take an example of ''multiplier = 2''.

* Scenario A: The system is quiet (5 active threads) 
50 + (2 × 5) = 60 faults/s 
Because only 5 threads are active, the baseline is 60 faults/s. If overall pool activity exceeds 60 faults/s, adjustment will kick in.
* Scenario B: Peak hours (200 active threads) 
50 + (2 × 200) = 450 faults/s 
Now 200 threads are actively sharing the pool, and adjustment scales its tolerance up to 450 faults/sec before it considers the pool "starved" enough to warrant moving memory from elsewhere.
* Scenario C: Extreme burst (600 active threads) 
50 + (2 × 600) = 1250 faults/s 
Because the absolute Maximum is capped at 1000, the math is clipped. The threshold stops scaling and locks firmly at 1000 faults/s.

=== Recommended adjustments ===
Values printed in ''bold'' are changed (non-default) values.

<blockquote>'''Note:''' These values are intended for small scale, or hobbyist systems. If these values hold up for heavy usage has not been established.</blockquote>

{|class="wikitable"
!colspan="2"| 
!colspan="2"|Size (%)
!colspan="3"|Faults/Second
|-
!Pool
!Priority
!Minimum
!Maximum
!Minimum
!Thread
!Maximum
|-
|*MACHINE
|align="right"|1
|align="right"|25.49<ref>Use literal <tt>*DFT</tt> to reset to default, if unsure.</ref>
|align="right"|'''50'''
|align="right"|'''100'''
|align="right"|0
|align="right"|'''100'''
|-
|*BASE
|align="right"|1
|align="right"|4.99
|align="right"|100
|align="right"|'''25'''
|align="right"|'''5'''
|align="right"|'''2000'''
|-
|*INTERACT
|align="right"|2
|align="right"|5
|align="right"|'''25'''
|align="right"|'''50'''
|align="right"|'''10'''
|align="right"|'''1000'''
|-
|*SPOOL
|align="right"|'''3'''
|align="right"|1
|align="right"|'''10'''
|align="right"|'''25'''
|align="right"|'''5'''
|align="right"|'''1000'''
|}

The primary goals behind the suggested values are:
* Establish hard ''Size %'' limits to prevent pool starvation.
* Allow for much higher faulting rates (''Faults/Second'') before taking action.
* Using higher scaling values still considers dynamic adjustment up to the raised ''Acceptable Fault Target Threshold'' values, and keeps the basic adjustment logic active.

== See also ==
* [[Post-Install Optimizations]]

== Footnotes ==
<references />

[[Category:Basic Knowledge]]
[[Category:Software Configuration Guide]]
[[Category:System Administration]]

Performance adjustment for Solid State Memory

2026-10-06T08:36:48Z

PoC: /* Work with Shared Pools */ Reworked

{{FIXME|Finish article}}
OS/400 '''Performance adjustment for Solid State Memory''' sheds some light on how to tune a system in regard to the almost zero latency for this type of secondary storage.

__TOC__

OS/400 is an ''paged virtual memory'' platform. There's no direct ''open a file and read the content into RAM'' system function. All data between secondary and primary storage (historically disk, and RAM) flows through the [[wikipedia:Memory paging|paging code]].

Today, disks are largely replaced with solid state, '''[[wikipedia:Flash memory|flash based memory]]'''. It has no moving mechanical parts, eliminates the accompanying access latency, generates no noise, draws less power, generates less heat, and often uses less physical space. Older AS/400 systems can benefit from the [[ZuluSCSI]] parallel SCSI disk emulator.

OS/400 features a so called '''performance adjustment''' function, which automatically splits and shifts available memory around between memory pools according to the current workload, the goal is to minimize paging activity. The default threshold values when, and how much memory is moved around are based on the relatively high latency of rotating disk drives. One particular data point is the ''faulting rate'', essentially how quickly the system tries to bring in data from secondary storage (disk) into primary storage (RAM) for processing. The higher the faulting rate, the more aggressive memory is moved between pools.

<blockquote>'''Note:''' Despite the word ''fault'' seemingly indicating a fatal condition, it isn't. A [[wikipedia:Page fault|page fault]] is a mere indicator that a requested memory location isn't in main storage and a different code path has to be taken to bring it into main storage before processing can commence. Also, a single page fault can result in multiple memory pages being copied into main storage at once.</blockquote>

Solid state memory allows very high paging rates, impossible with spinning disk drives, but without introducing excessive latency. The performance adjust doesn't base adjustment calculations on latency, but on faulting rate. On a system with much disk activity, this can lead to memory starvation of less active pools, and frequent invalidation of in-memory cached data due to quick reassignments of memory.

== Work with Shared Pools ==
The <code>wrkshrpool</code> command allows to adjust threshold values for the performance adjuster by pressing <code>F11</code>. You'll be presented with a table akin to the following. This table shows default values (for V4R5):
{|class="wikitable"
!colspan="2"| 
!colspan="2"|Size (%)
!colspan="3"|Faults/Second
|-
!Pool
!Priority
!Minimum
!Maximum
!Minimum
!Thread
!Maximum
|-
|*MACHINE
|align="right"|1
|align="right"|~25<ref>This value is calculated by the system.</ref>
|align="right"|100
|align="right"|10
|align="right"|0
|align="right"|10
|-
|*BASE
|align="right"|1
|align="right"|4.99
|align="right"|100
|align="right"|5
|align="right"|0.5
|align="right"|2000
|-
|*INTERACT
|align="right"|2
|align="right"|5
|align="right"|100
|align="right"|10
|align="right"|2
|align="right"|100
|-
|*SPOOL
|align="right"|2
|align="right"|1
|align="right"|100
|align="right"|5
|align="right"|1
|align="right"|100
|}

A pool's ''priority'' is a relative number from 1 to 14. Lower numbers mean higher priority for pools to be served with additional memory, while higher numbered pools are stripped from excess memory earlier.

Some explanation to the meaning of the ''Faults/Second'' values:
* '''Minimum''': If a pool's faulting rate drops below this value, the adjuster views the pool as over-allocated and will begin to strip memory away from it to feed other pools.
* '''Thread''': A multiplier per (active) thread.
* '''Maximum''': If the pool's faulting rate exceeds this value, the adjuster considers the pool starved and starts aggressively moving memory into it from other pools.

=== Thread multiplier ===
Explanation by example: If one user is running an application in the *INTERACT pool and causing 50 faults/second, that single user is experiencing a performance bottleneck. Contrary, if 100 people are using *INTERACT simultaneously and causing the same 50 faults/second, that means each user is only experiencing 0.5 faults/second. No bottleneck.

The system calculates a ''Dynamic Acceptable Fault Target Threshold = Minimum + (Thread Multiplier × Active Threads)''. If that value exceeds the absolute Maximum value, the latter is considered. Let's take an example of ''multiplier = 2''.

* Scenario A: The system is quiet (5 active threads) 
50 + (2 × 5) = 60 faults/s 
Because only 5 threads are active, the baseline is 60 faults/s. If overall pool activity exceeds 60 faults/s, adjustment will kick in.
* Scenario B: Peak hours (200 active threads) 
50 + (2 × 200) = 450 faults/s 
Now 200 threads are actively sharing the pool, and adjustment scales its tolerance up to 450 faults/sec before it considers the pool "starved" enough to warrant moving memory from elsewhere.
* Scenario C: Extreme burst (600 active threads) 
50 + (2 × 600) = 1250 faults/s 
Because the absolute Maximum is capped at 1000, the math is clipped. The threshold stops scaling and locks firmly at 1000 faults/s.

=== Recommended adjustments ===
Values printed in ''bold'' are changed (non-default) values.

<blockquote>'''Note:''' These values are intended for small scale, or hobbyist systems. If these values hold up for heavy usage has not been established.</blockquote>

{|class="wikitable"
!colspan="2"| 
!colspan="2"|Size (%)
!colspan="3"|Faults/Second
|-
!Pool
!Priority
!Minimum
!Maximum
!Minimum
!Thread
!Maximum
|-
|*MACHINE
|align="right"|1
|align="right"|25.49<ref>Use literal <tt>*DFT</tt> to reset to default, if unsure.</ref>
|align="right"|'''50'''
|align="right"|'''100'''
|align="right"|0
|align="right"|'''100'''
|-
|*BASE
|align="right"|1
|align="right"|4.99
|align="right"|100
|align="right"|'''25'''
|align="right"|'''5'''
|align="right"|'''2000'''
|-
|*INTERACT
|align="right"|2
|align="right"|5
|align="right"|'''25'''
|align="right"|'''50'''
|align="right"|'''10'''
|align="right"|'''1000'''
|-
|*SPOOL
|align="right"|'''3'''
|align="right"|1
|align="right"|'''10'''
|align="right"|'''25'''
|align="right"|'''5'''
|align="right"|'''1000'''
|}

The primary goals behind the suggested values are:
* Establish hard ''Size %'' limits to prevent pool starvation.
* Allow for much higher faulting rates (''Faults/Second'') before taking action.
* Using higher scaling values still considers dynamic adjustment up to the raised absolute maximum values, and keeps the basic adjustment logic active.

== See also ==
* [[Post-Install Optimizations]]

== Footnotes ==
<references />

[[Category:Basic Knowledge]]
[[Category:Software Configuration Guide]]
[[Category:System Administration]]

Performance adjustment for Solid State Memory

2026-10-06T08:05:43Z

PoC: /* Work with Shared Pools */ Priority

{{FIXME|Finish article}}
OS/400 '''Performance adjustment for Solid State Memory''' sheds some light on how to tune a system in regard to the almost zero latency for this type of secondary storage.

__TOC__

OS/400 is an ''paged virtual memory'' platform. There's no direct ''open a file and read the content into RAM'' system function. All data between secondary and primary storage (historically disk, and RAM) flows through the [[wikipedia:Memory paging|paging code]].

Today, disks are largely replaced with solid state, '''[[wikipedia:Flash memory|flash based memory]]'''. It has no moving mechanical parts, eliminates the accompanying access latency, generates no noise, draws less power, generates less heat, and often uses less physical space. Older AS/400 systems can benefit from the [[ZuluSCSI]] parallel SCSI disk emulator.

OS/400 features a so called '''performance adjustment''' function, which automatically splits and shifts available memory around between memory pools according to the current workload, the goal is to minimize paging activity. The default threshold values when, and how much memory is moved around are based on the relatively high latency of rotating disk drives. One particular data point is the ''faulting rate'', essentially how quickly the system tries to bring in data from secondary storage (disk) into primary storage (RAM) for processing. The higher the faulting rate, the more aggressive memory is moved between pools.

<blockquote>'''Note:''' Despite the word ''fault'' seemingly indicating a fatal condition, it isn't. A [[wikipedia:Page fault|page fault]] is a mere indicator that a requested memory location isn't in main storage and a different code path has to be taken to bring it into main storage before processing can commence. Also, a single page fault can result in multiple memory pages being copied into main storage at once.</blockquote>

Solid state memory allows very high paging rates, impossible with spinning disk drives, but without introducing excessive latency. The performance adjust doesn't base adjustment calculations on latency, but on faulting rate. On a system with much disk activity, this can lead to memory starvation of less active pools, and frequent invalidation of in-memory cached data due to quick reassignments of memory.

== Work with Shared Pools ==
The <code>wrkshrpool</code> command allows to adjust threshold values for the performance adjuster by pressing <code>F11</code>. You'll be presented with a table akin to the following. Suggested adjustment values are shown below. Values printed in ''bold'' are changed (non-default) values.

{|class="wikitable"
!colspan="2"| 
!colspan="2"|Size (%)
!colspan="3"|Faults/Second
|-
!Pool
!Priority
!Minimum
!Maximum
!Minimum
!Thread
!Maximum
|-
|*MACHINE
|align="right"|1
|align="right"|25.49<ref>Use literal <tt>*DFT</tt> to reset to default, if unsure.</ref>
|align="right"|'''50'''
|align="right"|'''100'''
|align="right"|0
|align="right"|'''100'''
|-
|*BASE
|align="right"|1
|align="right"|4.99
|align="right"|100
|align="right"|'''25'''
|align="right"|'''5'''
|align="right"|'''2000'''
|-
|*INTERACT
|align="right"|2
|align="right"|5
|align="right"|'''25'''
|align="right"|'''50'''
|align="right"|'''10'''
|align="right"|'''1000'''
|-
|*SPOOL
|align="right"|'''3'''
|align="right"|1
|align="right"|'''10'''
|align="right"|'''25'''
|align="right"|'''5'''
|align="right"|'''1000'''
|}

A pool's ''priority'' is a relative number from 1 to 14. Lower numbers mean higher priority for pools to be served with additional memory, while higher numbered pools are stripped from excess memory earlier.

Some explanation to the meaning of the ''Faults/Second'' values:
* '''Minimum''': If a pool's faulting rate drops below this value, the adjuster views the pool as over-allocated and will begin to strip memory away from it to feed other pools.
* '''Thread''': A multiplier per (active) thread.
* '''Maximum''': If the pool's faulting rate exceeds this value, the adjuster considers the pool starved and starts aggressively moving memory into it from other pools.

The primary goals behind the suggested values are
* Establish hard ''Size %'' limits to prevent pool starvation
* Allow for much higher faulting rates (''Faults/Second'') before taking action

=== Thread multiplier ===
Explanation by example: If one user is running an application in the *INTERACT pool and causing 50 faults/second, that single user is experiencing a performance bottleneck. Contrary, if 100 people are using *INTERACT simultaneously and causing the same 50 faults/second, that means each user is only experiencing 0.5 faults/second. No bottleneck.

The system calculates a ''Dynamic Acceptable Fault Target Threshold = Minimum + (Thread Multiplier × Active Threads)''. If that value exceeds the absolute Maximum value, the latter is considered. Let's take an example of ''multiplier = 2''.

* Scenario A: The system is quiet (5 active threads) 
50 + (2 × 5) = 60 faults/s 
Because only 5 threads are active, the baseline is 60 faults/s. If overall pool activity exceeds 60 faults/s, adjustment will kick in.
* Scenario B: Peak hours (200 active threads) 
50 + (2 × 200) = 450 faults/s 
Now 200 threads are actively sharing the pool, and adjustment scales its tolerance up to 450 faults/sec before it considers the pool "starved" enough to warrant moving memory from elsewhere.
* Scenario C: Extreme burst (600 active threads) 
50 + (2 × 600) = 1250 faults/s 
Because the absolute Maximum is capped at 1000, the math is clipped. The threshold stops scaling and locks firmly at 1000 faults/s.

Using higher scaling values still considers dynamic adjustment up to the raised absolute maximum values, and keeps the basic adjustment logic active.

== See also ==
* [[Post-Install Optimizations]]

== Footnotes ==
<references />

[[Category:Basic Knowledge]]
[[Category:Software Configuration Guide]]
[[Category:System Administration]]

Performance adjustment for Solid State Memory

2026-10-06T07:54:48Z

PoC: /* Thread multiplier */ Better wording

{{FIXME|Finish article}}
OS/400 '''Performance adjustment for Solid State Memory''' sheds some light on how to tune a system in regard to the almost zero latency for this type of secondary storage.

__TOC__

OS/400 is an ''paged virtual memory'' platform. There's no direct ''open a file and read the content into RAM'' system function. All data between secondary and primary storage (historically disk, and RAM) flows through the [[wikipedia:Memory paging|paging code]].

Today, disks are largely replaced with solid state, '''[[wikipedia:Flash memory|flash based memory]]'''. It has no moving mechanical parts, eliminates the accompanying access latency, generates no noise, draws less power, generates less heat, and often uses less physical space. Older AS/400 systems can benefit from the [[ZuluSCSI]] parallel SCSI disk emulator.

OS/400 features a so called '''performance adjustment''' function, which automatically splits and shifts available memory around between memory pools according to the current workload, the goal is to minimize paging activity. The default threshold values when, and how much memory is moved around are based on the relatively high latency of rotating disk drives. One particular data point is the ''faulting rate'', essentially how quickly the system tries to bring in data from secondary storage (disk) into primary storage (RAM) for processing. The higher the faulting rate, the more aggressive memory is moved between pools.

<blockquote>'''Note:''' Despite the word ''fault'' seemingly indicating a fatal condition, it isn't. A [[wikipedia:Page fault|page fault]] is a mere indicator that a requested memory location isn't in main storage and a different code path has to be taken to bring it into main storage before processing can commence. Also, a single page fault can result in multiple memory pages being copied into main storage at once.</blockquote>

Solid state memory allows very high paging rates, impossible with spinning disk drives, but without introducing excessive latency. The performance adjust doesn't base adjustment calculations on latency, but on faulting rate. On a system with much disk activity, this can lead to memory starvation of less active pools, and frequent invalidation of in-memory cached data due to quick reassignments of memory.

== Work with Shared Pools ==
The <code>wrkshrpool</code> command allows to adjust threshold values for the performance adjuster by pressing <code>F11</code>. You'll be presented with a table akin to the following. Suggested adjustment values are shown below. Values printed in ''bold'' are changed (non-default) values.

{|class="wikitable"
!colspan="2"| 
!colspan="2"|Size (%)
!colspan="3"|Faults/Second
|-
!Pool
!Priority
!Minimum
!Maximum
!Minimum
!Thread
!Maximum
|-
|*MACHINE
|align="right"|1
|align="right"|25.49<ref>Use literal <tt>*DFT</tt> to reset to default, if unsure.</ref>
|align="right"|'''50'''
|align="right"|'''100'''
|align="right"|0
|align="right"|'''100'''
|-
|*BASE
|align="right"|1
|align="right"|4.99
|align="right"|100
|align="right"|'''25'''
|align="right"|'''5'''
|align="right"|'''2000'''
|-
|*INTERACT
|align="right"|2
|align="right"|5
|align="right"|'''25'''
|align="right"|'''50'''
|align="right"|'''10'''
|align="right"|'''1000'''
|-
|*SPOOL
|align="right"|'''3'''
|align="right"|1
|align="right"|'''10'''
|align="right"|'''25'''
|align="right"|'''5'''
|align="right"|'''1000'''
|}

Some explanation to the meaning of the ''Faults/Second'' values:
* '''Minimum''': If a pool's faulting rate drops below this value, the adjuster views the pool as over-allocated and will begin to strip memory away from it to feed other pools.
* '''Thread''': A multiplier per (active) thread.
* '''Maximum''': If the pool's faulting rate exceeds this value, the adjuster considers the pool starved and starts aggressively moving memory into it from other pools.

The primary goals behind the suggested values are
* Establish hard ''Size %'' limits to prevent pool starvation
* Allow for much higher faulting rates (''Faults/Second'') before taking action

=== Thread multiplier ===
Explanation by example: If one user is running an application in the *INTERACT pool and causing 50 faults/second, that single user is experiencing a performance bottleneck. Contrary, if 100 people are using *INTERACT simultaneously and causing the same 50 faults/second, that means each user is only experiencing 0.5 faults/second. No bottleneck.

The system calculates a ''Dynamic Acceptable Fault Target Threshold = Minimum + (Thread Multiplier × Active Threads)''. If that value exceeds the absolute Maximum value, the latter is considered. Let's take an example of ''multiplier = 2''.

* Scenario A: The system is quiet (5 active threads) 
50 + (2 × 5) = 60 faults/s 
Because only 5 threads are active, the baseline is 60 faults/s. If overall pool activity exceeds 60 faults/s, adjustment will kick in.
* Scenario B: Peak hours (200 active threads) 
50 + (2 × 200) = 450 faults/s 
Now 200 threads are actively sharing the pool, and adjustment scales its tolerance up to 450 faults/sec before it considers the pool "starved" enough to warrant moving memory from elsewhere.
* Scenario C: Extreme burst (600 active threads) 
50 + (2 × 600) = 1250 faults/s 
Because the absolute Maximum is capped at 1000, the math is clipped. The threshold stops scaling and locks firmly at 1000 faults/s.

Using higher scaling values still considers dynamic adjustment up to the raised absolute maximum values, and keeps the basic adjustment logic active.

== See also ==
* [[Post-Install Optimizations]]

== Footnotes ==
<references />

[[Category:Basic Knowledge]]
[[Category:Software Configuration Guide]]
[[Category:System Administration]]

Performance adjustment for Solid State Memory

2026-10-06T07:51:45Z

PoC: /* Work with Shared Pools */ Thread multiplier explained

{{FIXME|Finish article}}
OS/400 '''Performance adjustment for Solid State Memory''' sheds some light on how to tune a system in regard to the almost zero latency for this type of secondary storage.

__TOC__

OS/400 is an ''paged virtual memory'' platform. There's no direct ''open a file and read the content into RAM'' system function. All data between secondary and primary storage (historically disk, and RAM) flows through the [[wikipedia:Memory paging|paging code]].

Today, disks are largely replaced with solid state, '''[[wikipedia:Flash memory|flash based memory]]'''. It has no moving mechanical parts, eliminates the accompanying access latency, generates no noise, draws less power, generates less heat, and often uses less physical space. Older AS/400 systems can benefit from the [[ZuluSCSI]] parallel SCSI disk emulator.

OS/400 features a so called '''performance adjustment''' function, which automatically splits and shifts available memory around between memory pools according to the current workload, the goal is to minimize paging activity. The default threshold values when, and how much memory is moved around are based on the relatively high latency of rotating disk drives. One particular data point is the ''faulting rate'', essentially how quickly the system tries to bring in data from secondary storage (disk) into primary storage (RAM) for processing. The higher the faulting rate, the more aggressive memory is moved between pools.

<blockquote>'''Note:''' Despite the word ''fault'' seemingly indicating a fatal condition, it isn't. A [[wikipedia:Page fault|page fault]] is a mere indicator that a requested memory location isn't in main storage and a different code path has to be taken to bring it into main storage before processing can commence. Also, a single page fault can result in multiple memory pages being copied into main storage at once.</blockquote>

Solid state memory allows very high paging rates, impossible with spinning disk drives, but without introducing excessive latency. The performance adjust doesn't base adjustment calculations on latency, but on faulting rate. On a system with much disk activity, this can lead to memory starvation of less active pools, and frequent invalidation of in-memory cached data due to quick reassignments of memory.

== Work with Shared Pools ==
The <code>wrkshrpool</code> command allows to adjust threshold values for the performance adjuster by pressing <code>F11</code>. You'll be presented with a table akin to the following. Suggested adjustment values are shown below. Values printed in ''bold'' are changed (non-default) values.

{|class="wikitable"
!colspan="2"| 
!colspan="2"|Size (%)
!colspan="3"|Faults/Second
|-
!Pool
!Priority
!Minimum
!Maximum
!Minimum
!Thread
!Maximum
|-
|*MACHINE
|align="right"|1
|align="right"|25.49<ref>Use literal <tt>*DFT</tt> to reset to default, if unsure.</ref>
|align="right"|'''50'''
|align="right"|'''100'''
|align="right"|0
|align="right"|'''100'''
|-
|*BASE
|align="right"|1
|align="right"|4.99
|align="right"|100
|align="right"|'''25'''
|align="right"|'''5'''
|align="right"|'''2000'''
|-
|*INTERACT
|align="right"|2
|align="right"|5
|align="right"|'''25'''
|align="right"|'''50'''
|align="right"|'''10'''
|align="right"|'''1000'''
|-
|*SPOOL
|align="right"|'''3'''
|align="right"|1
|align="right"|'''10'''
|align="right"|'''25'''
|align="right"|'''5'''
|align="right"|'''1000'''
|}

Some explanation to the meaning of the ''Faults/Second'' values:
* '''Minimum''': If a pool's faulting rate drops below this value, the adjuster views the pool as over-allocated and will begin to strip memory away from it to feed other pools.
* '''Thread''': A multiplier per (active) thread.
* '''Maximum''': If the pool's faulting rate exceeds this value, the adjuster considers the pool starved and starts aggressively moving memory into it from other pools.

The primary goals behind the suggested values are
* Establish hard ''Size %'' limits to prevent pool starvation
* Allow for much higher faulting rates (''Faults/Second'') before taking action

=== Thread multiplier ===
Explanation by example: If one user is running an application in the *INTERACT pool and causing 50 faults/second, that single user is experiencing a performance bottleneck. Contrary, if 100 people are using *INTERACT simultaneously and causing the same 50 faults/second, that means each user is only experiencing 0.5 faults/second. No bottleneck.

The system calculates a ''dynamic Maximum = Minimum + (Thread Multiplier × Active Threads)''. If that value exceeds the absolute Maximum value, the latter is considered. Let's take an example of ''multiplier = 2''.

* Scenario A: The system is quiet (5 active threads) 
50 + (2 × 5) = 60 faults/s 
Because only 5 threads are active, the baseline is 60 faults/s. If overall pool activity exceeds 60 faults/s, adjustment will kick in.
* Scenario B: Peak hours (200 active threads) 
50 + (2 × 200) = 450 faults/s 
Now 200 threads are actively sharing the pool, and adjustment scales its tolerance up to 450 faults/sec before it considers the pool "starved" enough to warrant moving memory from elsewhere.
* Scenario C: Extreme burst (600 active threads) 
50 + (2 × 600) = 1250 faults/s 
Because the absolute Maximum is capped at 1000, the math is clipped. The threshold stops scaling and locks firmly at 1000 faults/s.

Using higher scaling values still considers dynamic adjustment up to the raised absolute maximum values, and keeps the basic adjustment logic active.

== See also ==
* [[Post-Install Optimizations]]

== Footnotes ==
<references />

[[Category:Basic Knowledge]]
[[Category:Software Configuration Guide]]
[[Category:System Administration]]

Performance adjustment for Solid State Memory

2026-10-06T07:30:25Z

PoC: Better wording: Paging ≠ Faulting

Performance adjustment for Solid State Memory

2026-10-05T23:16:16Z

PoC: New

ZuluSCSI

2026-09-22T19:52:21Z

PoC: Moved content to GitHub repo

Terminal graphics support

2026-09-18T16:25:16Z

PoC: typo

There are three modes of '''graphics support''' in OS/400 regarding '''terminals'''.

== GDDM ==
A subset of the mainframe ''Graphical Data Display Manager'' was ported to OS/400.

GDDM needs special support regarding terminals. The only existing twinax terminal supporting GDDM was the 5292 model 2.

Emulators supporting GDDM:
* IBM PC support for DOS (not verified), with special drivers, resolutions up to 1024×768 might be possible,
* an older IDEAcomm release for Windows 3.1 (16 bit), precise version not known.

In later times, it was presumably meant as a way to create graphics for printing.

== Enhanced display ==
This is a function of the 5250 controller in tandem with a hardware terminal, or a feature of the emulator itself. It provides automatic replacement of on-screen objects with a more or less graphical representation of an object. This includes, but is not limited to:
* Window borders
* DDS<ref>Should also work with UIM panels, but not real life tested.</ref> <code>MLTCHCFLD</code> as check boxes
* DDS <code>SNGCHCFLD</code> as radio buttons
* DDS <code>SFLEND(*SCRBAR)</code> for load-all subfiles

Enhanced display needs special support regarding terminals. It is present at least in the twinax 3486 terminal, but presumably in all 348x terminals.

Emulators supporting Enhanced Display:
* all (newer?) IBM provided 5250 emulators
** iACS
** Client Access
* tn5250j (seems to be broken)

== APA ==
''All Points Addressable'' is IBM lingo for pixel graphics support. Little is known about this mode at all, and its sole use case was the <code>dspfax</code> command, to see received Faxes in TIFFG4 format.

According to documentation, the 3489 is the only hardware terminal supporting this display mode.

No known emulators support APA.

== See also ==
* [[IBM Twinax-Terminals Overview]]
* [[Communications Traces]]

== Weblinks ==
* [https://www.ibm.com/docs/en/i/7.4.0?topic=device-application-display-programming Application Display Programming] (PDF download), IBM.com

== Footnotes ==
<references />

[[Category: History]]
[[Category: System Internals]]

Terminal graphics support

2026-09-18T16:24:26Z

PoC: /* APA */ typo, not md

There are three modes of '''graphics support''' in OS/400 regarding '''terminals'''.

== GDDM ==
A subset of the mainframe ''Graphical Data Display Manager'' was ported to OS/400.

GDDM needs special support regarding terminals. The only existing twinax terminal supporting GDDM was the 5292 model 2.

Emulators supporting GDDM:
* IBM PC support for DOS (not verified), with special drivers, resolutions up to 1024×768 might be possible,
* an older IDEAcomm release for Windows 3.1 (16 bit), precise version not known.

In later times, it was presumably meant as a way to create graphics for printing.

== Enhanced display ==
This is a function of the 5250 controller in tandem with a hardware terminal, or a feature of the emulator itself. It provides automatic replacement of on-screen objects with a more or less graphical representation of an object. This includes, but is not limited to:
* Window borders
* DDS<ref>Should also work with UIM tags, but not real life tested.</ref> <code>MLTCHCFLD</code> as check boxes
* DDS <code>SNGCHCFLD</code> as radio buttons
* DDS <code>SFLEND(*SCRBAR)</code> for load-all subfiles

Enhanced display needs special support regarding terminals. It is present at least in the twinax 3486 terminal, but presumably in all 348x terminals.

Emulators supporting Enhanced Display:
* all (newer?) IBM provided 5250 emulators
** iACS
** Client Access
* tn5250j (seems to be broken)

== APA ==
''All Points Addressable'' is IBM lingo for pixel graphics support. Little is known about this mode at all, and its sole use case was the <code>dspfax</code> command, to see received Faxes in TIFFG4 format.

According to documentation, the 3489 is the only hardware terminal supporting this display mode.

No known emulators support APA.

== See also ==
* [[IBM Twinax-Terminals Overview]]
* [[Communications Traces]]

== Weblinks ==
* [https://www.ibm.com/docs/en/i/7.4.0?topic=device-application-display-programming Application Display Programming] (PDF download), IBM.com

== Footnotes ==
<references />

[[Category: History]]
[[Category: System Internals]]

Terminal graphics support

2026-09-18T16:23:29Z

PoC: New

There are three modes of '''graphics support''' in OS/400 regarding '''terminals'''.

== GDDM ==
A subset of the mainframe ''Graphical Data Display Manager'' was ported to OS/400.

GDDM needs special support regarding terminals. The only existing twinax terminal supporting GDDM was the 5292 model 2.

Emulators supporting GDDM:
* IBM PC support for DOS (not verified), with special drivers, resolutions up to 1024×768 might be possible,
* an older IDEAcomm release for Windows 3.1 (16 bit), precise version not known.

In later times, it was presumably meant as a way to create graphics for printing.

== Enhanced display ==
This is a function of the 5250 controller in tandem with a hardware terminal, or a feature of the emulator itself. It provides automatic replacement of on-screen objects with a more or less graphical representation of an object. This includes, but is not limited to:
* Window borders
* DDS<ref>Should also work with UIM tags, but not real life tested.</ref> <code>MLTCHCFLD</code> as check boxes
* DDS <code>SNGCHCFLD</code> as radio buttons
* DDS <code>SFLEND(*SCRBAR)</code> for load-all subfiles

Enhanced display needs special support regarding terminals. It is present at least in the twinax 3486 terminal, but presumably in all 348x terminals.

Emulators supporting Enhanced Display:
* all (newer?) IBM provided 5250 emulators
** iACS
** Client Access
* tn5250j (seems to be broken)

== APA ==
''All Points Addressable'' is IBM lingo for pixel graphics support. Little is known about this mode at all, and its sole use case was the `dspfax` command, to see received Faxes in TIFFG4 format.

According to documentation, the 3489 is the only hardware terminal supporting this display mode.

No known emulators support APA.

== See also ==
* [[IBM Twinax-Terminals Overview]]
* [[Communications Traces]]

== Weblinks ==
* [https://www.ibm.com/docs/en/i/7.4.0?topic=device-application-display-programming Application Display Programming] (PDF download), IBM.com

== Footnotes ==
<references />

[[Category: History]]
[[Category: System Internals]]

ZuluSCSI

2026-09-10T16:10:32Z

PoC: /* Tape drive support */ missing word

'''ZuluSCSI''' by Rabbit Hole Computing is a comparatively new family of SCSI device emulators featuring an SD card based backing store. Distinct features to older, similar devices is support for Wide-SCSI, Ultra-Speed, and a fast CPU.

ZuluSCSI also features an OpenSource firmware, so it can be extended comparatively easily.

__TOC__

For most AS/400 machines, you actually want a ZuluSCSI wide, because it offers the best performance.

The ZuluSCSI firmware can emulate multiple devices at once. There is no real need to add multiple Zulus to a given SCSI bus. One Zulu can easily saturate even the UltraWide SCSI bus of a 9401-150, and due to the SD card, delays are minimal. You can gain more performance with bigger machines, if they have multiple SCSI buses, though.

<blockquote>'''Note:''' Current state of affairs is that at least for writes, the SD card itself is a considerable brake shoe for writes, presumably because of so called 'Write Amplification''. This is not meant to stay like this forever. Optimizations are possible and will be implemented eventually.</blockquote>

== Hardware overview ==
Depending on the exact model, boards themselves have three DIP switches and tiny push buttons:
* 1: switch to initator mode,
* 2: enable debug log,
* 3: enable SCSI termination.

The push buttons call the functions:
* Bootloader, for firmware-recovery,
* Eject.

Also, three LEDs are provided, for indication of
* 2.8 V power OK,
* 3.3 V power OK,
* SD-card activity.

The device itself needs 5 V power, and can be powered by:
* the USB port,
* the termpower line of the SCSI bus,
* molex style power connectors.

Usually, the integrated USB port is configured as USB modem, for usage with a terminal emulator. You can use the Linux or macOS ''screen'' command for that. Depending on your operating system, you need to find out what device file is created when plugging the Zulu's USB port. On Linux, it's <tt>/dev/ttyACM''n''</tt> — ''n'' being a digit, usually 0. On macOS, it's <tt>/dev/tty.usbmodem*</tt>, with a row of digits appended on behalf of the <tt>*</tt>.

The firmware presents a simple menu driven UI for some tasks.

There is no need to shut down the device itself, it's safe to "pull the plug" when there is no activity. The Operating System running on the attached computer should be orderly shut down, though.

== Configuration ==
Configuration itself is usually automatic, according to the files and directories found on the SD card. The SD card has either a FAT32<ref>Limiting files to max. 4 GiB in size</ref> or exFAT file system, the firmware understands both. It's easier to use the SD card with a card reader on a newer computer to create configurations, and files. The SD card is hotplug capable, and upon reinsertation, the ZuluSCSI reinitializes itself according to the SD card's content.

Three devices classes are of general interest in the AS/400 world:
* Disk (DASD),
* CD/DVD (Optical),
* Tape.

=== Files ===
File names are composed as follows:
<nowiki><TT><ID>[any text].<ext></nowiki>
^^ ^
| +-------------- SCSI ID character (byte offset 2)
+------------------- two-character type prefix (case-insensitive)

* '''TT''':
:{|class="wikitable"
!TT
!Device type
!Default block size
|-
|HD
|Hard disk (fixed)
|align="right"|512 Bytes
|-
|CD
|CD-ROM (optical)
|align="right"|2048 Bytes
|-
|TP
|Sequential (tape)
|align="right"|512 Bytes
|}
* The '''ID''' is exactly one char, and must be given in hexadecimal. This matters only for IDs ≥ 10.
* '''any text''' is entirely optional.
* The '''file extension''' doesn't matter.

=== Directories ===
For a device usually allowing dynamic addition and removal of media — CD-ROM-, and tape drives, you can create a directory instead of a file. The naming scheme follows the same structure as files, but ''[any text]'' must be omitted.

Files within the directories can be freely named. The ''Eject'' button loads and inserts the next image in order. Individual images can be inserted through the menu via USB.

=== Configuration file ===
In addition, a configuration file can be supplied to provide additional information to either all or one emulated device. Having a ''zuluscsi.ini'' is normally optional, but for enabling AS/400 quirks, it's mandatory.

The configuration file must be named ''zuluscsi.ini'', and is in a simple ini-style format. It has a global <tt>[SCSI]</tt> section to apply settings to all devices, and <tt>[SCSI''n'']</tt>, where ''n'' is the ID of the given SCSI devices.

== Examples ==
These are in the scope of AS/400.

=== Tape drive support ===
Currently, two tape drives are emulated:
* <code>Device = "AS400_CISC"</code>, a CISC era QIC1000, FC #6343,
* <code>Device = "AS400_PPC"</code>, a PCI/RISC era SLR5 drive.

To use,
* create directory <code>TP0</code>,
* populate with one or more 0 byte files named <code>*.tap</code> files, e. g. by using the Unix <code>touch</code> command,
* use the serial console to attach image(s) to the drive.

Without any ''Device'' parameter, a standard tape drive is emulated, with no special AS/400 quirks. This works with many PPC/PCI machines. However, the presence of a ''TapeDensity'' parameter seems necessary in ''zuluscsi.ini''.
[SCSI0]
TapeDensity = 0x25

For trying an emulated SLR5 drive:
* ''zuluscsi.ini'':
[SCSI0]
Device = "AS400_PPC"

Caveats:
* When you choose an image file through the USB port's media menu, make sure that you not only choose an image file, but afterwards ''insert'' it!
* If you replace a hardware tape drive, make sure to delete your old tape device file first, then IPL, check/set the new device name in DST, and have auto-configuration create the new device file during the following IPL.
* The amended (with an explicit ''Device'' statement) tape code as of v2026.08.28 has not yet undergone extensive testing. Initial tests yield mixed results.

=== CD drive support ===
* create directory <code>CD0</code>,
* populate with one or more readymade ISO images,
* use the serial console to attach image(s) to the drive.

No special handling for the ID in ''zuluscsi.ini''.

Caveats:
* When you choose an image file through the USB port's media menu, make sure that you not only choose an image file, but afterwards ''insert'' it!
* If you replace a hardware CD drive, make sure to delete your old CD device file first, then IPL, check/set the new device name in DST, and have auto-configuration create the new device file during the following IPL.

Tested with Firmware 2026-08-07, 9401-150, V4R4, V5R2: IPL only so far, but that works. '''Note:''' CISC era OS/400 has no CD-ROM support whatsoever.

=== Disk drive support ===
The officially released code base is able to present multiple disk drives to the system, initialize, and install SLIC + base OS/400 + LPPs + PTFs.

* Copy ''as400_disk_definitions.txt'' from the official GitHub repository to the SD card.
** Because of serial numbers currently being hard coded, only one disk per type should be used for now!
* ''zuluscsi.ini'':
[SCSI]
System = AS400_PPC

[SCSI6]
AS400_DiskProfile = "09L4044"
PrefetchBytes = 0

When a ''AS400_DiskProfile'' is configured for a given SCSI ID, and the associated image cannot be found on the SD card, a new one is generated automatically, with the correct size. This takes some time, so wait until the activity LED stays unlit.

There is a shell-script <code>utils/extract_as400_disk_data.sh</code> in the original source tree on GitHub to generate more ''as400_disk_definitions.txt'' entries from real disks connected to a SCSI controller when ran under Linux.

Caveats:
* Writes to the emulated disk are very slow compared to reads.

Fully tested with Firmware v2026.08.27RC1, 9401-150, V4R4, V5R2.

== Current state ==
We have to differ three hardware generations when considering Zulu vs. AS/400:
{|class="wikitable"
! 
!CISC/IMPI, 520 bytes/block disks
!RISC/SPD, 520/522 bytes/block disks
!RISC/PCI, 522 bytes/block disks
|-
!CD-ROM
|Not supported
|Untested
|Works
|-
!Tape
|Fails, hangs with SRC early.
|Untested
|Works
|-
!Disk
|Fails, hangs with SRC early.
|Untested
|Works
|}

All successful tests so far have been based on a ZuluSCSI wide board on a 9401-150, while the CISC tests have been done with a ZuluSCSI Blaster on a 9401-P02.

There are success reports of more 150's working, and one of a 9406-270 becoming stuck with A6000244, ''Contact was lost with device indicated''.

== See also ==
* [[Ordinary Harddisks on the AS/400]]
* [[Tape Drives on old AS/400]]
* [[SRC]], aka System Reference Code

== Weblinks ==
* [https://zuluscsi.com ZuluSCSI Website] — see the <tt>☰</tt> button top right for more details
* [https://github.com/ZuluSCSI/ZuluSCSI-firmware ZuluSCSI-firmware], GitHub

== Footnotes ==
<references />

[[Category:Hardware Configuration Guide]]

ZuluSCSI

2026-09-10T16:09:38Z

PoC: /* Tape drive support */ Rework

'''ZuluSCSI''' by Rabbit Hole Computing is a comparatively new family of SCSI device emulators featuring an SD card based backing store. Distinct features to older, similar devices is support for Wide-SCSI, Ultra-Speed, and a fast CPU.

ZuluSCSI also features an OpenSource firmware, so it can be extended comparatively easily.

__TOC__

For most AS/400 machines, you actually want a ZuluSCSI wide, because it offers the best performance.

The ZuluSCSI firmware can emulate multiple devices at once. There is no real need to add multiple Zulus to a given SCSI bus. One Zulu can easily saturate even the UltraWide SCSI bus of a 9401-150, and due to the SD card, delays are minimal. You can gain more performance with bigger machines, if they have multiple SCSI buses, though.

<blockquote>'''Note:''' Current state of affairs is that at least for writes, the SD card itself is a considerable brake shoe for writes, presumably because of so called 'Write Amplification''. This is not meant to stay like this forever. Optimizations are possible and will be implemented eventually.</blockquote>

== Hardware overview ==
Depending on the exact model, boards themselves have three DIP switches and tiny push buttons:
* 1: switch to initator mode,
* 2: enable debug log,
* 3: enable SCSI termination.

The push buttons call the functions:
* Bootloader, for firmware-recovery,
* Eject.

Also, three LEDs are provided, for indication of
* 2.8 V power OK,
* 3.3 V power OK,
* SD-card activity.

The device itself needs 5 V power, and can be powered by:
* the USB port,
* the termpower line of the SCSI bus,
* molex style power connectors.

Usually, the integrated USB port is configured as USB modem, for usage with a terminal emulator. You can use the Linux or macOS ''screen'' command for that. Depending on your operating system, you need to find out what device file is created when plugging the Zulu's USB port. On Linux, it's <tt>/dev/ttyACM''n''</tt> — ''n'' being a digit, usually 0. On macOS, it's <tt>/dev/tty.usbmodem*</tt>, with a row of digits appended on behalf of the <tt>*</tt>.

The firmware presents a simple menu driven UI for some tasks.

There is no need to shut down the device itself, it's safe to "pull the plug" when there is no activity. The Operating System running on the attached computer should be orderly shut down, though.

== Configuration ==
Configuration itself is usually automatic, according to the files and directories found on the SD card. The SD card has either a FAT32<ref>Limiting files to max. 4 GiB in size</ref> or exFAT file system, the firmware understands both. It's easier to use the SD card with a card reader on a newer computer to create configurations, and files. The SD card is hotplug capable, and upon reinsertation, the ZuluSCSI reinitializes itself according to the SD card's content.

Three devices classes are of general interest in the AS/400 world:
* Disk (DASD),
* CD/DVD (Optical),
* Tape.

=== Files ===
File names are composed as follows:
<nowiki><TT><ID>[any text].<ext></nowiki>
^^ ^
| +-------------- SCSI ID character (byte offset 2)
+------------------- two-character type prefix (case-insensitive)

* '''TT''':
:{|class="wikitable"
!TT
!Device type
!Default block size
|-
|HD
|Hard disk (fixed)
|align="right"|512 Bytes
|-
|CD
|CD-ROM (optical)
|align="right"|2048 Bytes
|-
|TP
|Sequential (tape)
|align="right"|512 Bytes
|}
* The '''ID''' is exactly one char, and must be given in hexadecimal. This matters only for IDs ≥ 10.
* '''any text''' is entirely optional.
* The '''file extension''' doesn't matter.

=== Directories ===
For a device usually allowing dynamic addition and removal of media — CD-ROM-, and tape drives, you can create a directory instead of a file. The naming scheme follows the same structure as files, but ''[any text]'' must be omitted.

Files within the directories can be freely named. The ''Eject'' button loads and inserts the next image in order. Individual images can be inserted through the menu via USB.

=== Configuration file ===
In addition, a configuration file can be supplied to provide additional information to either all or one emulated device. Having a ''zuluscsi.ini'' is normally optional, but for enabling AS/400 quirks, it's mandatory.

The configuration file must be named ''zuluscsi.ini'', and is in a simple ini-style format. It has a global <tt>[SCSI]</tt> section to apply settings to all devices, and <tt>[SCSI''n'']</tt>, where ''n'' is the ID of the given SCSI devices.

== Examples ==
These are in the scope of AS/400.

=== Tape drive support ===
Currently, two tape drives are emulated:
* <code>Device = "AS400_CISC"</code>, a CISC era QIC1000, FC #6343,
* <code>Device = "AS400_PPC"</code>, a PCI/RISC era SLR5 drive.

To use,
* create directory <code>TP0</code>,
* populate with one or more 0 byte files named <code>*.tap</code> files, e. g. by using the Unix <code>touch</code>,
* use the serial console to attach image(s) to the drive.

Without any ''Device'' parameter, a standard tape drive is emulated, with no special AS/400 quirks. This works with many PPC/PCI machines. However, the presence of a ''TapeDensity'' parameter seems necessary in ''zuluscsi.ini''.
[SCSI0]
TapeDensity = 0x25

For trying an emulated SLR5 drive:
* ''zuluscsi.ini'':
[SCSI0]
Device = "AS400_PPC"

Caveats:
* When you choose an image file through the USB port's media menu, make sure that you not only choose an image file, but afterwards ''insert'' it!
* If you replace a hardware tape drive, make sure to delete your old tape device file first, then IPL, check/set the new device name in DST, and have auto-configuration create the new device file during the following IPL.
* The amended (with an explicit ''Device'' statement) tape code as of v2026.08.28 has not yet undergone extensive testing. Initial tests yield mixed results.

=== CD drive support ===
* create directory <code>CD0</code>,
* populate with one or more readymade ISO images,
* use the serial console to attach image(s) to the drive.

No special handling for the ID in ''zuluscsi.ini''.

Caveats:
* When you choose an image file through the USB port's media menu, make sure that you not only choose an image file, but afterwards ''insert'' it!
* If you replace a hardware CD drive, make sure to delete your old CD device file first, then IPL, check/set the new device name in DST, and have auto-configuration create the new device file during the following IPL.

Tested with Firmware 2026-08-07, 9401-150, V4R4, V5R2: IPL only so far, but that works. '''Note:''' CISC era OS/400 has no CD-ROM support whatsoever.

=== Disk drive support ===
The officially released code base is able to present multiple disk drives to the system, initialize, and install SLIC + base OS/400 + LPPs + PTFs.

* Copy ''as400_disk_definitions.txt'' from the official GitHub repository to the SD card.
** Because of serial numbers currently being hard coded, only one disk per type should be used for now!
* ''zuluscsi.ini'':
[SCSI]
System = AS400_PPC

[SCSI6]
AS400_DiskProfile = "09L4044"
PrefetchBytes = 0

When a ''AS400_DiskProfile'' is configured for a given SCSI ID, and the associated image cannot be found on the SD card, a new one is generated automatically, with the correct size. This takes some time, so wait until the activity LED stays unlit.

There is a shell-script <code>utils/extract_as400_disk_data.sh</code> in the original source tree on GitHub to generate more ''as400_disk_definitions.txt'' entries from real disks connected to a SCSI controller when ran under Linux.

Caveats:
* Writes to the emulated disk are very slow compared to reads.

Fully tested with Firmware v2026.08.27RC1, 9401-150, V4R4, V5R2.

== Current state ==
We have to differ three hardware generations when considering Zulu vs. AS/400:
{|class="wikitable"
! 
!CISC/IMPI, 520 bytes/block disks
!RISC/SPD, 520/522 bytes/block disks
!RISC/PCI, 522 bytes/block disks
|-
!CD-ROM
|Not supported
|Untested
|Works
|-
!Tape
|Fails, hangs with SRC early.
|Untested
|Works
|-
!Disk
|Fails, hangs with SRC early.
|Untested
|Works
|}

All successful tests so far have been based on a ZuluSCSI wide board on a 9401-150, while the CISC tests have been done with a ZuluSCSI Blaster on a 9401-P02.

There are success reports of more 150's working, and one of a 9406-270 becoming stuck with A6000244, ''Contact was lost with device indicated''.

== See also ==
* [[Ordinary Harddisks on the AS/400]]
* [[Tape Drives on old AS/400]]
* [[SRC]], aka System Reference Code

== Weblinks ==
* [https://zuluscsi.com ZuluSCSI Website] — see the <tt>☰</tt> button top right for more details
* [https://github.com/ZuluSCSI/ZuluSCSI-firmware ZuluSCSI-firmware], GitHub

== Footnotes ==
<references />

[[Category:Hardware Configuration Guide]]

IBM BOOK format

2026-09-10T08:57:47Z

PoC: Updated page

'''IBM BookManager Softcopy''' is IBM's legacy online documentation system, created in the 1980s. It was historically used mostly on mainframes, midrange (AS/400) and OS/2, although it also saw some use in other areas including AIX.

IBM no longer uses it for new documentations of its products, but there is an immense quantity of legacy electronic documentation from the period when IBM actively used it (from the 1980s thru 2010s), particularly documentation CD-ROMs/DVD-ROMs and images thereof.

The file-internal style (?) format apparently is called IBMIDDOC.

The standard DOS style extension is <code>BOO</code>, and "application/book" is sometimes used as MIME type, but was never officially registered.

== Internal structure ==
The internal structure is fully documented as a part of the ''Geist'' reference implementation on GitHub.

== See also ==
* [[Reviving InfoSeeker]]

== Weblinks ==
* [https://github.com/cyberdotgent/geist Geist IBM Book format reference implementation]
** [https://github.com/cyberdotgent/geist/tree/main/doc/boo-spec Geist Book format documentation]
* [http://www.edm2.com/index.php/BookManager BookManager Releases] contains history of IBM BookManager releases
* [https://www.ibm.com/support/pages/using-pdfs-and-bookmanager-books-your-workstation-or-mainframe Using PDFs and BookManager Books on your workstation or mainframe], IBM.com
* [https://en.wikipedia.org/wiki/Terse_(file_format) Terse (file format)], Wikipedia
* [https://en.wikipedia.org/wiki/LZ77_and_LZ78 LZ77 and LZ78] compression algorithms, Wikipedia
* [https://patents.google.com/patent/US4814746A/en?oq=4814746 Data compression method] for TERSE, patents.google.com
* [http://fileformats.archiveteam.org/wiki/ZIP ZIP archive file format], archiveteam.org, mentions TERSE.
* [https://hercules-390.yahoogroups.narkive.com/gYwJ3QUu/terse-for-pcs-windows-aix-linux terse for PCs (Windows, AIX, Linux ....)], hercules-390@yahoogroups.com
* [https://bit.listserv.ibm-main.narkive.com/82nDDwrh/trsmain-question TRSMAIN question], IBM-Main mailing list
* [https://share.confex.com/share/121/webprogram/Handout/Session14242/14242-%20zOS%20Documentation%20Search%20Strategies%20%28Final%20Edition%29.pdf 14242: z/OS Documentation Search Strategies], presentation slides in PDF format

== Footnotes ==
<references />

[[Category: System Internals]]

ZuluSCSI

2026-09-08T12:15:29Z

PoC: /* Examples */ More precise on tapes

'''ZuluSCSI''' by Rabbit Hole Computing is a comparatively new family of SCSI device emulators featuring an SD card based backing store. Distinct features to older, similar devices is support for Wide-SCSI, Ultra-Speed, and a fast CPU.

ZuluSCSI also features an OpenSource firmware, so it can be extended comparatively easily.

__TOC__

For most AS/400 machines, you actually want a ZuluSCSI wide, because it offers the best performance.

The ZuluSCSI firmware can emulate multiple devices at once. There is no real need to add multiple Zulus to a given SCSI bus. One Zulu can easily saturate even the UltraWide SCSI bus of a 9401-150, and due to the SD card, delays are minimal. You can gain more performance with bigger machines, if they have multiple SCSI buses, though.

<blockquote>'''Note:''' Current state of affairs is that at least for writes, the SD card itself is a considerable brake shoe for writes, presumably because of so called 'Write Amplification''. This is not meant to stay like this forever. Optimizations are possible and will be implemented eventually.</blockquote>

== Hardware overview ==
Depending on the exact model, boards themselves have three DIP switches and tiny push buttons:
* 1: switch to initator mode,
* 2: enable debug log,
* 3: enable SCSI termination.

The push buttons call the functions:
* Bootloader, for firmware-recovery,
* Eject.

Also, three LEDs are provided, for indication of
* 2.8 V power OK,
* 3.3 V power OK,
* SD-card activity.

The device itself needs 5 V power, and can be powered by:
* the USB port,
* the termpower line of the SCSI bus,
* molex style power connectors.

Usually, the integrated USB port is configured as USB modem, for usage with a terminal emulator. You can use the Linux or macOS ''screen'' command for that. Depending on your operating system, you need to find out what device file is created when plugging the Zulu's USB port. On Linux, it's <tt>/dev/ttyACM''n''</tt> — ''n'' being a digit, usually 0. On macOS, it's <tt>/dev/tty.usbmodem*</tt>, with a row of digits appended on behalf of the <tt>*</tt>.

The firmware presents a simple menu driven UI for some tasks.

There is no need to shut down the device itself, it's safe to "pull the plug" when there is no activity. The Operating System running on the attached computer should be orderly shut down, though.

== Configuration ==
Configuration itself is usually automatic, according to the files and directories found on the SD card. The SD card has either a FAT32<ref>Limiting files to max. 4 GiB in size</ref> or exFAT file system, the firmware understands both. It's easier to use the SD card with a card reader on a newer computer to create configurations, and files. The SD card is hotplug capable, and upon reinsertation, the ZuluSCSI reinitializes itself according to the SD card's content.

Three devices classes are of general interest in the AS/400 world:
* Disk (DASD),
* CD/DVD (Optical),
* Tape.

=== Files ===
File names are composed as follows:
<nowiki><TT><ID>[any text].<ext></nowiki>
^^ ^
| +-------------- SCSI ID character (byte offset 2)
+------------------- two-character type prefix (case-insensitive)

* '''TT''':
:{|class="wikitable"
!TT
!Device type
!Default block size
|-
|HD
|Hard disk (fixed)
|align="right"|512 Bytes
|-
|CD
|CD-ROM (optical)
|align="right"|2048 Bytes
|-
|TP
|Sequential (tape)
|align="right"|512 Bytes
|}
* The '''ID''' is exactly one char, and must be given in hexadecimal. This matters only for IDs ≥ 10.
* '''any text''' is entirely optional.
* The '''file extension''' doesn't matter.

=== Directories ===
For a device usually allowing dynamic addition and removal of media — CD-ROM-, and tape drives, you can create a directory instead of a file. The naming scheme follows the same structure as files, but ''[any text]'' must be omitted.

Files within the directories can be freely named. The ''Eject'' button loads and inserts the next image in order. Individual images can be inserted through the menu via USB.

=== Configuration file ===
In addition, a configuration file can be supplied to provide additional information to either all or one emulated device. Having a ''zuluscsi.ini'' is normally optional, but for enabling AS/400 quirks, it's mandatory.

The configuration file must be named ''zuluscsi.ini'', and is in a simple ini-style format. It has a global <tt>[SCSI]</tt> section to apply settings to all devices, and <tt>[SCSI''n'']</tt>, where ''n'' is the ID of the given SCSI devices.

== Examples ==
These are in the scope of AS/400.

=== Tape drive support ===
Currently, two tape drives are emulated:
* a CISC era QIC1000, FC #6343,
* a PCI/RISC era SLR5 drive.

* create directory <code>TP0</code>,
* populate with one or more 0 byte files named <code>*.tap</code> files, e. g. by using the Unix <code>touch</code>,
* use the serial console to attach image(s) to the drive.
* ''zuluscsi.ini'':
[SCSI0]
Device = "AS400_PPC"

Caveats:
* When you choose an image file through the USB port's media menu, make sure that you not only choose an image file, but afterwards ''insert'' it!
* If you replace a hardware tape drive, make sure to delete your old tape device file first, then IPL, check/set the new device name in DST, and have auto-configuration create the new device file during the following IPL.
* The amended (with an explicit ''Device'' statement) tape code as of v2026.08.28 has not yet undergone extensive testing. Initial tests yield mixed results.

=== CD drive support ===
* create directory <code>CD0</code>,
* populate with one or more readymade ISO images,
* use the serial console to attach image(s) to the drive.

No special handling for the ID in ''zuluscsi.ini''.

Caveats:
* When you choose an image file through the USB port's media menu, make sure that you not only choose an image file, but afterwards ''insert'' it!
* If you replace a hardware CD drive, make sure to delete your old CD device file first, then IPL, check/set the new device name in DST, and have auto-configuration create the new device file during the following IPL.

Tested with Firmware 2026-08-07, 9401-150, V4R4, V5R2: IPL only so far, but that works. '''Note:''' CISC era OS/400 has no CD-ROM support whatsoever.

=== Disk drive support ===
The officially released code base is able to present multiple disk drives to the system, initialize, and install SLIC + base OS/400 + LPPs + PTFs.

* Copy ''as400_disk_definitions.txt'' from the official GitHub repository to the SD card.
** Because of serial numbers currently being hard coded, only one disk per type should be used for now!
* ''zuluscsi.ini'':
[SCSI]
System = AS400_PPC

[SCSI6]
AS400_DiskProfile = "09L4044"
PrefetchBytes = 0

When a ''AS400_DiskProfile'' is configured for a given SCSI ID, and the associated image cannot be found on the SD card, a new one is generated automatically, with the correct size. This takes some time, so wait until the activity LED stays unlit.

There is a shell-script <code>utils/extract_as400_disk_data.sh</code> in the original source tree on GitHub to generate more ''as400_disk_definitions.txt'' entries from real disks connected to a SCSI controller when ran under Linux.

Caveats:
* Writes to the emulated disk are very slow compared to reads.

Fully tested with Firmware v2026.08.27RC1, 9401-150, V4R4, V5R2.

== Current state ==
We have to differ three hardware generations when considering Zulu vs. AS/400:
{|class="wikitable"
! 
!CISC/IMPI, 520 bytes/block disks
!RISC/SPD, 520/522 bytes/block disks
!RISC/PCI, 522 bytes/block disks
|-
!CD-ROM
|Not supported
|Untested
|Works
|-
!Tape
|Fails, hangs with SRC early.
|Untested
|Works
|-
!Disk
|Fails, hangs with SRC early.
|Untested
|Works
|}

All successful tests so far have been based on a ZuluSCSI wide board on a 9401-150, while the CISC tests have been done with a ZuluSCSI Blaster on a 9401-P02.

There are success reports of more 150's working, and one of a 9406-270 becoming stuck with A6000244, ''Contact was lost with device indicated''.

== See also ==
* [[Ordinary Harddisks on the AS/400]]
* [[Tape Drives on old AS/400]]
* [[SRC]], aka System Reference Code

== Weblinks ==
* [https://zuluscsi.com ZuluSCSI Website] — see the <tt>☰</tt> button top right for more details
* [https://github.com/ZuluSCSI/ZuluSCSI-firmware ZuluSCSI-firmware], GitHub

== Footnotes ==
<references />

[[Category:Hardware Configuration Guide]]

Panel Usage

2026-09-06T19:42:13Z

PoC: /* Elements */ Amber LED

Every AS/400 or later machines have a '''panel''', either as hardware, or emulated in Software (for logical partitions, ''LPAR''s).

== Elements ==
The panel is comprised of these elements:
* Pushbutton ↑
* Pushbutton ↓
* Pushbutton ''Enter'' often colored blue,
* LC-Display, for output of System Reference Codes (SRC),
* Power pushbutton ⌽,
* LED (green) for showing the power state,
* LED (green), with a pictogram reminding of stairs (main processor activity),<ref>It is not the disk activity LED as it was usual with PCs was into the 2000s.</ref>
* LED (amber) with a vertical bar, cut in half and one half moved slightly horizontal (error<ref>In other words: System activity is halted and will not try to recover until a reset is issued. Reset means power cycle.</ref>).

Usually after plugging the power, the LCD will light up green.

== Changing settings ==
Normally, the LCD shows two chars and two digits, like
01 B N
The meaning is:
* 01 - Show current IPL-Parameters
* B - (A B C D) IPL-Source
* N (N M) IPL-Mode

<blockquote>Beware, the panel allows to set a multitude of parameters to the system service processor card. Please don't wildly push buttons to see what will happen. Chances are you will change a setting and the machine will no longer IPL, or console connection is broken, or probably worse things.</blockquote>

=== Setting IPL Mode to source D, and mode manual ===
This example setting is needed to make the machine IPL from install media, such as tape or optical.

* Push ↑ once to set the digit display from 01 to 02. Confirm with ''Enter''.
* Push ↑ oder ↓ until the character display is showing <code>D M</code>.<ref>Older machines support concurrent setting of Source and Mode, newer support setting Source and Mode separately.</ref> Confirm with ''Enter''.
* Push the power button ⌽. You can now insert the I_BASE-CD into the optical drive.

== See also ==
* [[SRC 0000BBBB]]

== Weblinks ==
* [https://www.ibm.com/docs/en/i/7.5.0?topic=functions-normal-control-panel Normal control panel functions], IBM.com

== Footnotes ==
<references />

[[Category:Basic Knowledge]]

Post-Install Optimizations

2026-09-03T16:23:04Z

PoC: /* Security System Values */ Typo

OS/400 provides a lot of default values for variables (affecting the run-time environment) and program options. Some of these make sense, some of them are kept consistent with earlier versions of the OS because of compatibility reasons by IBM.

Some of these recommendations might not be appropriate for you by various reasons. Don't apply blindly. Know what you do, use the online help to retrieve background information on the topic in question.

The findings below are based on V4R5 with annotated exceptions for newer releases.

== Housekeeping ==
These are settings and scheduled jobs to keep your system uncluttered.

=== Change unneeded programs to not run ===
We most likely don't need to run ''lpd'' and ''smtpd'' to run per default.
CHGLPDA AUTOSTART(*NO)
CHGSMTPA AUTOSTART(*NO)

You can easily check all settings at once by using <code>UPDDTA QUSRSYS/QATOCSTART</code>. These are not needed in general.
* *DIRSRV
* *NETSVR
* *SLP

Depending on OS version, not all entries may be available.

=== Change uninstalled programs to not run ===
If you did not install the Ultimedia package, you can remove the pre started job from the QSYSWRK subsystem description to make it not generate an error message at IPL time.
RMVPJE SBSD(QSYSWRK) PGM(QUMEDIA/QUMBPJTC)

If you did not install the Directory Services package (aka LDAP), you can remove the auto started jobs from the QSYSWRK subsystem description to make them not generate an error message at IPL time.
RMVAJE SBSD(QSYSWRK) JOB(QGLDPUBA)
RMVAJE SBSD(QSYSWRK) JOB(QGLDPUBE)

Both is valid and tested for V4R5. Note that newer releases moved the background jobs to the base OS so there is no error message when starting them. I have not tested if they're required to run, though.

If you did not install the performance tools, you don't need trying to start the performance data collector:
RMVAJE SBSD(QCTL) JOB(QPFRCOL)

I can't remember if the latter is valid for V4R5. It's valid for V3R2, though.

=== Cleanup unneeded stuff ===
These objects come by default at OS install time, are not needed to my knowledge, and thus can be safely deleted:
DLTOUTQ OUTQ(QDKT)
DLTOUTQ OUTQ(QPFROUTQ)
DLTOUTQ OUTQ(QPRINTS)
DLTF FILE(QPRINTS)
DLTOUTQ OUTQ(QPRINT2)
DLTF FILE(QPRINT2)
DLTOUTQ OUTQ(QTPPPOUTQ)
DLTDEVD DEVD(QESPAP)
DLTDEVD DEVD(QIADSP)
DLTDEVD DEVD(QIAPRT)
DLTDEVD DEVD(QQAHOST)
DLTDEVD DEVD(QTIDA)
DLTDEVD DEVD(QTIDA2)
DLTCTLD CTLD(QESCTL)
DLTCTLD CTLD(QTICTL)
DLTLIND LIND(QESLINE)
DLTLIND LIND(QTILINE)

== System Values ==
System values are like environment variables as known from common operating systems. They influence system operation. I recommend the following changes.

=== System Control ===
* Change work environment to separate subsystems for different kind of jobs. This also makes it easy to introduce your own subsystems.
CHGSYSVAL SYSVAL(QCTLSBSD) VALUE('QCTL QSYS')
* Set automatic DST adjustment, and UTC offset. This value is valid for Central Europe (Berlin, Paris, …) '''Note!''' This variable is not available in V4R5. See [[#Weblinks|Weblinks]] below.
CHGSYSVAL SYSVAL(QTIMZON) VALUE('QP0100CET2')
* Adjust time to automatically end disconnected interactive jobs (sessions) to one day.
CHGSYSVAL SYSVAL(QDSCJOBITV) VALUE('1440')

=== (Memory) Allocation ===
* Adjust automatic performance values only at runtime, not at IPL.<ref>If you change the amount of memory for the machine, temporarily adjust the value to '2', make the memory change and then change the value back to '3' — no further IPL needed.</ref> This allows the system to automatically adjust memory allocations and activity levels to minimize paging (disk I/O).
CHGSYSVAL SYSVAL(QPFRADJ) VALUE('3')
* Allow memory pools to self adjust the paging block size depending on jobs running. This is called ''Expert Cache''. You can adjust the maximum active jobs per pool in the <code>WRKSHRPOOL</code> display.<ref>Press <code>F21</code> to switch to view 2 or 3 to have adjustment possibilities.</ref>
CHGSHRPOOL POOL(*BASE) PAGING(*CALC)
CHGSHRPOOL POOL(*INTERACT) PAGING(*CALC)
CHGSHRPOOL POOL(*SPOOL) PAGING(*CALC)
* Reservations for job related data structures at IPL time. See <code>DSPSYSSTS</code> and set to slightly more than the ''Jobs in System'' value to be seen there when the system is working "normal".<ref>Press <code>F21</code> to switch to view 2 or 3 to see the overall job count.</ref>
CHGSYSVAL SYSVAL(QTOTJOB) VALUE(100)
* Reservations for job related data structures at IPL time. See <code>WRKACTJOB</code> and set to slightly more than the ''Active Jobs'' value to be seen there when the system is working "normal".
CHGSYSVAL SYSVAL(QACTJOB) VALUE(95)
* Maximize TCP buffers for maximum performance, especially on faster links.
CHGTCPA TCPRCVBUF(8388608) TCPSNDBUF(8388608)
* Make sure, database tasks can use system resources as needed.
CHGSYSVAL SYSVAL(QQRYDEGREE) VALUE(*OPTIMIZE)
* When interactive jobs require more CPU time than being allowed by default (2 seconds),<ref>This is set in *CLS objects.</ref> to finish a block of processing, allow that memory to be taken from the *BASE pool. Advantage: The QINTER subsystem pool will not be subject to auto adjustment because of jobs which are supposed to run in batch.
CHGSYSVAL SYSVAL(QTSEPOOL) VALUE(*BASE)

=== Message-and-Logging ===
* Allow immediate deletion of problem reports.
CHGSYSVAL SYSVAL(QPRBHLDITV) VALUE(0)
* Do not log software errors. We can't do much about these anyway, seen from a hobbyist viewpoint.
CHGSYSVAL SYSVAL(QSFWERRLOG) VALUE(*NOLOG)
* Maximize Central Syslog (viewable with <code>DSPLOG</code> size to lessen rotation frequency. Depending on OS version only ''VALUE(32767)'' may be valid.
CHGSYSVAL SYSVAL(QHSTLOGSIZ) VALUE(*DAILY)
* Raise allowed unsuccessful sign on tries before taking action.
CHGSYSVAL SYSVAL(QMAXSIGN) VALUE('15')
* Minimize logging for sessions disconnected beause of device errors.
CHGSYSVAL SYSVAL(QDEVRCYACN) VALUE(*ENDJOBNOLIST)

=== Security System Values ===
* Unrestrict automatic creation of system objects triggered by external (network) requests.
CHGSYSVAL SYSVAL(QAUTOVRT) VALUE(*NOMAX)
* Allow restore with all security relevant flags.
CHGSYSVAL SYSVAL(QALWOBJRST) VALUE(*ALL)
* For TCP connections to work, we need encrypted passwords.
CHGDDMTCPA PWDRQD(*ENCRYPTED)
* Allow ''QSYSOPR'' sign-on to all devices.
CHGSYSVAL SYSVAL(QLMTSECOFR) VALUE('0')
* Raise maximum password length to maximum value.<ref>In newer OS versions, an additional variable ''QPWDLVL'' allows even longer passwords.</ref>
CHGSYSVAL SYSVAL(QPWDMAXLEN) VALUE(10)
* Raise minimum passsword length for security reasons.
CHGSYSVAL SYSVAL(QPWDMINLEN) VALUE(8)

=== Misc ===
* PTF install shall be done on unattended IPL time, and don't try to report problems to IBM directly.<ref>Needs prior setup for ''Electronic Customer Support''.</ref>
CHGSRVA PTFINSTYP(*DLYALL) RPTPRBAUTO(*NO)
* Provide European style formatting.
CHGSYSVAL SYSVAL(QCURSYM) VALUE('€')
CHGSYSVAL SYSVAL(QDECFMT) VALUE('J')
CHGSYSVAL SYSVAL(QSRTSEQ) VALUE(*LANGIDUNQ)<ref>This value isn't available with V4R5. You can use ''*LANGIDSHR'' there.</ref>
CHGSYSVAL SYSVAL(QDATFMT) VALUE('DMY')<ref>Default value for 2924 (US English) is MDY.</ref>
* Allow background compiling in PDM as ordinary user, and submitting batch jobs in general.
GRTOBJAUT OBJ(QGPL/QBATCH) OBJTYPE(*JOBD) USER(*PUBLIC) AUT(*USE)
* Tweaking automatic cleanup (like ''logrotate'').
CHGCLNUP ALWCLNUP(*YES) STRTIME('02:22:22') USRMSG(7) SYSMSG(3) SYSPRT(7) SYSLOG(14) CALITM(*KEEP)
* Change general SNA networking attributes. This is one '''long''' line. Take care to get it completely.
CHGNETA JOBACN(*SEARCH) VRTAUTODEV(254) MDMCNTRYID(DE)

=== Charset Conversion ===
In addition, OS/400 has a default value of 65535 for <code>QCCSID</code>. It should be set to a value being dependent on the installed language, to enable automatic translation of data on disk to the display device, and back. For Germany, the correct value is 273, and for US, it's 37. A good hint is to check your 5250 emulator program for possible values.

== IPL Customization ==
With this procedure, the current startup program for the OS can be retrieved for easy customization.
RTVCLSRC PGM(QSTRUP) SRCFILE(QCLSRC)
WRKMBRPDM FILE(QCLSRC) MBR(QSTRUP) MBRTYPE(CLP)
CRTCLPGM PGM(QGPL/QSTRUP)

To activate your changes, run <code>WRKSYSVAL SYSVAL(QSTRUPPGM)</code> and change the values to reflect the new program object in QGPL. '''Note''': On a used system's install, the previous owner might have already done a customized QSTRUP. See <code>DSPSYSVAL QSTRUPPGM</code> which one is the currently set startup program before accidentally overwriting!

Notable use cases for changing <code>QSTRUP</code> would be to make SNA Distribution Services, and TCP/IP (on older releases than V4R5) start at IPL time.

New entries must be located after the ''IF COND'' statement and ''DONE:'' label. Always put a ''MONMSG MSGID(CPF0000)'' after each statement. Failing to do so will not ignore any errors but make the IPL script terminate abnormally in case of an error and possibly leave you with an inaccessible system.

Examples:
* Start TCP/IP:
QSYS/STRTCP
MONMSG MSGID(CPF0000)
<blockquote>'''Note:''' TCP/IP on V4R5 and later is by IBM provided default automatically started with an appropriate autostart entry <code>struptcpip</code> in the <code>qsyswrk</code> subsystem description. No action is necessary in the startup CL!</blockquote>

* Start SNADS:
QSYS/STRSBS SBSD(QSNADS)
MONMSG MSGID(CPF0000)

== Change Program Defaults ==
This establishes different default behavior of some programs which makes life somewhat easier.<ref>Some people highly oppose against changing default values because the default values have been provided for a reason. But then, the <code>CHGCMDDFT</code> also has been provided for a reason.</ref> At least noting down the changed programs and their former values is recommended, for example in <code>QGPL/QTXTSRC.CMDDFT</code>.
<blockquote>'''Note:''' CL applications might run a command with the changed default values, in turn combining (new) defaults and submitted parameters into an invalid combination of parameters which might lead to run-time errors. As far as I'm aware, my proposed changes are compatible with such situations.</blockquote>

* File creation and change defaults:
** Enforce immediate return to program error handling instead of make programs seem to hang (<code>wait…</code>),
** Enforce reusing deleted record space,<ref>If there is no access path defined, sequentially read records are no longer guaranteed to *be in timely order (FIFO)!</ref>
** Remove sizing restrictions,<ref>A runaway process filling the disks to 100 % is not stopped prior!</ref>
** Use a smaller access path size for probably increased performance,
** Allow automatic LF rebuild when running <code>chgpf</code>.
CHGCMDDFT CMD(CRTPF) NEWDFT('SIZE(*NOMAX *N *N) WAITFILE(*IMMED) WAITRCD(*IMMED) REUSEDLT(*YES)')
CHGCMDDFT CMD(CRTSRCPF) NEWDFT('SIZE(*NOMAX *N *N) ACCPTHSIZ(*MAX4GB)')
CHGCMDDFT CMD(CHGPF) NEWDFT('DLTDEPLF(*YES) SIZE(*NOMAX *N *N) WAITFILE(*IMMED) WAITRCD(*IMMED) REUSEDLT(*YES)')
CHGCMDDFT CMD(CRTLF) NEWDFT('WAITFILE(*IMMED) WAITRCD(*IMMED) ACCPTHSIZ(*MAX4GB)')
CHGCMDDFT CMD(CHGLF) NEWDFT('WAITFILE(*IMMED) WAITRCD(*IMMED) ACCPTHSIZ(*MAX4GB)')
* Menus usually go into the library with the application's other objects. Change current library to there, so applications can find their objects.<ref>It might be beneficial to individually use <code>CURLIB(*NOCHG)</code> for higher level menu objects being put into libraries which are part of the default library search list (''*LIBL'') — such as ''QGPL'' — to not needlessly change the default library in a for some users unexpected way.</ref>
CHGCMDDFT CMD(CRTMNU) NEWDFT('CURLIB(*MNULIB)')
* No unnecessary wait for power down. <code>CONFIRM(*NO)</code> can be added for newer releases to suppress prompting.
CHGCMDDFT CMD(PWRDWNSYS) NEWDFT('OPTION(*IMMED) ENDSBSOPT(*NOJOBLOG)')
* Don't waste time displaying a not so very much interesting screen prior to connection.
CHGCMDDFT CMD(STRPASTHR) NEWDFT('PASTHRSCN(*NO)')

Be aware that reinstalls, or applying PTFs can overwrite command objects and thus their changed default values. Also note, hat installing a secondary language on a system also installs a separate set of <code>*cmd</code> objects for that language. You may want to apply the defaults with qualified object names to these, too.

== Regular Cleanup jobs ==
See job comment TEXT for details. These are '''long''' lines. Take care to get it completely.
ADDJOBSCDE JOB(PRGPRB) CMD(DLTPRB STATUS(*CLOSED)) FRQ(*WEEKLY) SCDDATE(*NONE) SCDDAY(*ALL) SCDTIME('13:22:00') MSGQ(*LIBL/QSYSOPR) TEXT('Purge closed and deletable problem entries')
ADDJOBSCDE JOB(RCLTMPSTG) CMD(RCLTMPSTG DAYS(30)) FRQ(*MONTHLY) SCDDATE(*MONTHSTR) SCDDAY(*NONE) SCDTIME('13:24:00') MSGQ(*LIBL/QSYSOPR) TEXT('Reclaim temporary storage')
ADDJOBSCDE JOB(RTVDSKINF) CMD(RTVDSKINF) FRQ(*MONTHLY) SCDDATE(*MONTHSTR) SCDDAY(*NONE) SCDTIME('13:34:00') MSGQ(*LIBL/QSYSOPR) TEXT('Retrieve disk space stats')
ADDJOBSCDE JOB(QPGMRCLR) CMD(CLRMSGQ MSGQ(QPGMR) CLEAR(*KEEPUNANS)) FRQ(*WEEKLY) SCDDATE(*NONE) SCDDAY(*ALL) SCDTIME('07:07:07') RCYACN(*NOSBM) MSGQ(*NONE) TEXT('Delete uninteresting messages')

== PTF handling ==
To save space on disk and backup media, you may want to consider applying all PTFs permanently. You cannot remove them afterwards, but that largely doesn't really matter for older and hobbyist systems.

From a console, first run an `ENDSYS (*IMMED)` to get the system into restricted, state. Then run
APYPTF LICPGM(*ALL) SELECT(*ALL) APY(*PERM) DELAYED(*YES) IPLAPY(*YES)

This will apply all PTFs permanently upon next normal IPL. Note you should IPL from the A-side to allow changes to the B side being made.

A final IPL to the B side gets you the fully PTF'd system.

== Re-Enable InfoSeeker ==
Only necessary for newer V4R4 and newer. If the command isn't known, don't bother: Then your release is so new that it's gone entirely.

See also: [[Reviving InfoSeeker]]

CRTDTAARA DTAARA(QUSRSYS/QBMGINFSKR) TYPE(*CHAR) LEN(8)<ref>Works in V4R5. The <code>STRINFSKR</code> command is not included anymore in IBM i 7.1, and probably earlier releases.</ref>

== Additional Steps tested with V7R2 ==
After trying to enter SST, one gets the message that the password has expired. But the password cannot be changed. Re-IPL '''in manual mode''', do not IPL but enter DST, and change password as directed.

* Choose ''5. Work with DST environment'' and ''3. Service tools user IDs''.
** Disable the "backdoor" profile ''11111111'',
** ''Change password'' for ''QSECOFR'', ''Set password to expired'' to ''2=No''.
* Press F12 and choose ''6. Service tools security data''.
** Enter 0 into the field ''8. Password expiration interval in days'', 8 into the ''Selection'' field, and press return.
** Enter a high number (like 12) into the field ''9. Maximum sign-on attempts allowed'', 9 into the ''Selection'' field, and press return.
** Enter 0 into the field ''10. Duplicate password control'', 10 into the ''Selection'' field, and press return.

Now exit DST.

You may choose to enter SST, enter 7 for ''Work with system security'', and set ''Allow a service tools user ID with a default and expired password to change its own password'' to ''1=Yes''. Since we changed password expiry to ''never'', this step is entirely optional.

== See also ==
* [[Change Command Defaults for File-Commands]]
* [[How to properly shut down your AS/400]]

== Weblinks ==
* [https://archive.midrange.com/midrange-l/199912/msg01738.html STRINFSKR], Midrange Mailing-List
* [https://github.com/PoC-dev/as400-autodst as400-autodst], GitHub

== Footnotes ==
<references />

[[Category: System Administration]]

ZuluSCSI

2026-08-29T20:59:40Z

PoC: /* Tape drive support */ Removed inert entry

'''ZuluSCSI''' by Rabbit Hole Computing is a comparatively new family of SCSI device emulators featuring an SD card based backing store. Distinct features to older, similar devices is support for Wide-SCSI, Ultra-Speed, and a fast CPU.

ZuluSCSI also features an OpenSource firmware, so it can be extended comparatively easily.

__TOC__

For most AS/400 machines, you actually want a ZuluSCSI wide, because it offers the best performance.

The ZuluSCSI firmware can emulate multiple devices at once. There is no real need to add multiple Zulus to a given SCSI bus. One Zulu can easily saturate even the UltraWide SCSI bus of a 9401-150, and due to the SD card, delays are minimal. You can gain more performance with bigger machines, if they have multiple SCSI buses, though.

<blockquote>'''Note:''' Current state of affairs is that at least for writes, the SD card itself is a considerable brake shoe for writes, presumably because of so called 'Write Amplification''. This is not meant to stay like this forever. Optimizations are possible and will be implemented eventually.</blockquote>

== Hardware overview ==
Depending on the exact model, boards themselves have three DIP switches and tiny push buttons:
* 1: switch to initator mode,
* 2: enable debug log,
* 3: enable SCSI termination.

The push buttons call the functions:
* Bootloader, for firmware-recovery,
* Eject.

Also, three LEDs are provided, for indication of
* 2.8 V power OK,
* 3.3 V power OK,
* SD-card activity.

The device itself needs 5 V power, and can be powered by:
* the USB port,
* the termpower line of the SCSI bus,
* molex style power connectors.

Usually, the integrated USB port is configured as USB modem, for usage with a terminal emulator. You can use the Linux or macOS ''screen'' command for that. Depending on your operating system, you need to find out what device file is created when plugging the Zulu's USB port. On Linux, it's <tt>/dev/ttyACM''n''</tt> — ''n'' being a digit, usually 0. On macOS, it's <tt>/dev/tty.usbmodem*</tt>, with a row of digits appended on behalf of the <tt>*</tt>.

The firmware presents a simple menu driven UI for some tasks.

There is no need to shut down the device itself, it's safe to "pull the plug" when there is no activity. The Operating System running on the attached computer should be orderly shut down, though.

== Configuration ==
Configuration itself is usually automatic, according to the files and directories found on the SD card. The SD card has either a FAT32<ref>Limiting files to max. 4 GiB in size</ref> or exFAT file system, the firmware understands both. It's easier to use the SD card with a card reader on a newer computer to create configurations, and files. The SD card is hotplug capable, and upon reinsertation, the ZuluSCSI reinitializes itself according to the SD card's content.

Three devices classes are of general interest in the AS/400 world:
* Disk (DASD),
* CD/DVD (Optical),
* Tape.

=== Files ===
File names are composed as follows:
<nowiki><TT><ID>[any text].<ext></nowiki>
^^ ^
| +-------------- SCSI ID character (byte offset 2)
+------------------- two-character type prefix (case-insensitive)

* '''TT''':
:{|class="wikitable"
!TT
!Device type
!Default block size
|-
|HD
|Hard disk (fixed)
|align="right"|512 Bytes
|-
|CD
|CD-ROM (optical)
|align="right"|2048 Bytes
|-
|TP
|Sequential (tape)
|align="right"|512 Bytes
|}
* The '''ID''' is exactly one char, and must be given in hexadecimal. This matters only for IDs ≥ 10.
* '''any text''' is entirely optional.
* The '''file extension''' doesn't matter.

=== Directories ===
For a device usually allowing dynamic addition and removal of media — CD-ROM-, and tape drives, you can create a directory instead of a file. The naming scheme follows the same structure as files, but ''[any text]'' must be omitted.

Files within the directories can be freely named. The ''Eject'' button loads and inserts the next image in order. Individual images can be inserted through the menu via USB.

=== Configuration file ===
In addition, a configuration file can be supplied to provide additional information to either all or one emulated device. Having a ''zuluscsi.ini'' is normally optional, but for enabling AS/400 quirks, it's mandatory.

The configuration file must be named ''zuluscsi.ini'', and is in a simple ini-style format. It has a global <tt>[SCSI]</tt> section to apply settings to all devices, and <tt>[SCSI''n'']</tt>, where ''n'' is the ID of the given SCSI devices.

== Examples ==
These are in the scope of AS/400.

=== Tape drive support ===
* create directory <code>TP0</code>,
* populate with one or more 0 byte files named <code>*.tap</code> files, e. g. by using the Unix <code>touch</code>,
* use the serial console to attach image(s) to the drive.
* ''zuluscsi.ini'':
[SCSI0]
Device = "AS400_PPC"

Caveats:
* When you choose an image file through the USB port's media menu, make sure that you not only choose an image file, but afterwards ''insert'' it!
* If you replace a hardware tape drive, make sure to delete your old tape device file first, then IPL, check/set the new device name in DST, and have auto-configuration create the new device file during the following IPL.
* The amended (with an explicit ''Device'' statement) tape code as of v2026.08.28 has not yet undergone extensive testing.

=== CD drive support ===
* create directory <code>CD0</code>,
* populate with one or more readymade ISO images,
* use the serial console to attach image(s) to the drive.

No special handling for the ID in ''zuluscsi.ini''.

Caveats:
* When you choose an image file through the USB port's media menu, make sure that you not only choose an image file, but afterwards ''insert'' it!
* If you replace a hardware CD drive, make sure to delete your old CD device file first, then IPL, check/set the new device name in DST, and have auto-configuration create the new device file during the following IPL.

Tested with Firmware 2026-08-07, 9401-150, V4R4, V5R2: IPL only so far, but that works.

=== Disk drive support ===
The officially released code base is able to present multiple disk drives to the system, initialize, and install SLIC + base OS/400 + LPPs + PTFs.

* Copy ''as400_disk_definitions.txt'' from the official GitHub repository to the SD card.
** Because of serial numbers currently being hard coded, only one disk per type should be used for now!
* ''zuluscsi.ini'':
[SCSI]
System = AS400_PPC

[SCSI6]
AS400_DiskProfile = "09L4044"
PrefetchBytes = 0

When a ''AS400_DiskProfile'' is configured for a given SCSI ID, and the associated image cannot be found on the SD card, a new one is generated automatically, with the correct size. This takes some time, so wait until the activity LED stays unlit.

There is a shell-script <code>utils/extract_as400_disk_data.sh</code> in the original source tree on GitHub to generate more ''as400_disk_definitions.txt'' entries from real disks connected to a SCSI controller when ran under Linux.

Caveats:
* Writes to the emulated disk are very slow compared to reads.

Fully tested with Firmware v2026.08.27RC1, 9401-150, V4R4, V5R2.

== Current state ==
We have to differ three hardware generations when considering Zulu vs. AS/400:
{|class="wikitable"
! 
!CISC/IMPI, 520 bytes/block disks
!RISC/SPD, 520/522 bytes/block disks
!RISC/PCI, 522 bytes/block disks
|-
!CD-ROM
|Not supported
|Untested
|Works
|-
!Tape
|Fails, hangs with SRC early.
|Untested
|Works
|-
!Disk
|Fails, hangs with SRC early.
|Untested
|Works
|}

All successful tests so far have been based on a ZuluSCSI wide board on a 9401-150, while the CISC tests have been done with a ZuluSCSI Blaster on a 9401-P02.

There are success reports of more 150's working, and one of a 9406-270 becoming stuck with A6000244, ''Contact was lost with device indicated''.

== See also ==
* [[Ordinary Harddisks on the AS/400]]
* [[Tape Drives on old AS/400]]
* [[SRC]], aka System Reference Code

== Weblinks ==
* [https://zuluscsi.com ZuluSCSI Website] — see the <tt>☰</tt> button top right for more details
* [https://github.com/ZuluSCSI/ZuluSCSI-firmware ZuluSCSI-firmware], GitHub

== Footnotes ==
<references />

[[Category:Hardware Configuration Guide]]

ZuluSCSI

2026-08-29T20:58:27Z

PoC: /* Tape drive support */ Typo

'''ZuluSCSI''' by Rabbit Hole Computing is a comparatively new family of SCSI device emulators featuring an SD card based backing store. Distinct features to older, similar devices is support for Wide-SCSI, Ultra-Speed, and a fast CPU.

ZuluSCSI also features an OpenSource firmware, so it can be extended comparatively easily.

__TOC__

For most AS/400 machines, you actually want a ZuluSCSI wide, because it offers the best performance.

The ZuluSCSI firmware can emulate multiple devices at once. There is no real need to add multiple Zulus to a given SCSI bus. One Zulu can easily saturate even the UltraWide SCSI bus of a 9401-150, and due to the SD card, delays are minimal. You can gain more performance with bigger machines, if they have multiple SCSI buses, though.

<blockquote>'''Note:''' Current state of affairs is that at least for writes, the SD card itself is a considerable brake shoe for writes, presumably because of so called 'Write Amplification''. This is not meant to stay like this forever. Optimizations are possible and will be implemented eventually.</blockquote>

== Hardware overview ==
Depending on the exact model, boards themselves have three DIP switches and tiny push buttons:
* 1: switch to initator mode,
* 2: enable debug log,
* 3: enable SCSI termination.

The push buttons call the functions:
* Bootloader, for firmware-recovery,
* Eject.

Also, three LEDs are provided, for indication of
* 2.8 V power OK,
* 3.3 V power OK,
* SD-card activity.

The device itself needs 5 V power, and can be powered by:
* the USB port,
* the termpower line of the SCSI bus,
* molex style power connectors.

Usually, the integrated USB port is configured as USB modem, for usage with a terminal emulator. You can use the Linux or macOS ''screen'' command for that. Depending on your operating system, you need to find out what device file is created when plugging the Zulu's USB port. On Linux, it's <tt>/dev/ttyACM''n''</tt> — ''n'' being a digit, usually 0. On macOS, it's <tt>/dev/tty.usbmodem*</tt>, with a row of digits appended on behalf of the <tt>*</tt>.

The firmware presents a simple menu driven UI for some tasks.

There is no need to shut down the device itself, it's safe to "pull the plug" when there is no activity. The Operating System running on the attached computer should be orderly shut down, though.

== Configuration ==
Configuration itself is usually automatic, according to the files and directories found on the SD card. The SD card has either a FAT32<ref>Limiting files to max. 4 GiB in size</ref> or exFAT file system, the firmware understands both. It's easier to use the SD card with a card reader on a newer computer to create configurations, and files. The SD card is hotplug capable, and upon reinsertation, the ZuluSCSI reinitializes itself according to the SD card's content.

Three devices classes are of general interest in the AS/400 world:
* Disk (DASD),
* CD/DVD (Optical),
* Tape.

=== Files ===
File names are composed as follows:
<nowiki><TT><ID>[any text].<ext></nowiki>
^^ ^
| +-------------- SCSI ID character (byte offset 2)
+------------------- two-character type prefix (case-insensitive)

* '''TT''':
:{|class="wikitable"
!TT
!Device type
!Default block size
|-
|HD
|Hard disk (fixed)
|align="right"|512 Bytes
|-
|CD
|CD-ROM (optical)
|align="right"|2048 Bytes
|-
|TP
|Sequential (tape)
|align="right"|512 Bytes
|}
* The '''ID''' is exactly one char, and must be given in hexadecimal. This matters only for IDs ≥ 10.
* '''any text''' is entirely optional.
* The '''file extension''' doesn't matter.

=== Directories ===
For a device usually allowing dynamic addition and removal of media — CD-ROM-, and tape drives, you can create a directory instead of a file. The naming scheme follows the same structure as files, but ''[any text]'' must be omitted.

Files within the directories can be freely named. The ''Eject'' button loads and inserts the next image in order. Individual images can be inserted through the menu via USB.

=== Configuration file ===
In addition, a configuration file can be supplied to provide additional information to either all or one emulated device. Having a ''zuluscsi.ini'' is normally optional, but for enabling AS/400 quirks, it's mandatory.

The configuration file must be named ''zuluscsi.ini'', and is in a simple ini-style format. It has a global <tt>[SCSI]</tt> section to apply settings to all devices, and <tt>[SCSI''n'']</tt>, where ''n'' is the ID of the given SCSI devices.

== Examples ==
These are in the scope of AS/400.

=== Tape drive support ===
* create directory <code>TP0</code>,
* populate with one or more 0 byte files named <code>*.tap</code> files, e. g. by using the Unix <code>touch</code>,
* use the serial console to attach image(s) to the drive.
* ''zuluscsi.ini'':
[SCSI]
System = "AS400_PPC"

[SCSI0]
Device = "AS400_PPC"

Caveats:
* When you choose an image file through the USB port's media menu, make sure that you not only choose an image file, but afterwards ''insert'' it!
* If you replace a hardware tape drive, make sure to delete your old tape device file first, then IPL, check/set the new device name in DST, and have auto-configuration create the new device file during the following IPL.
* The amended (with an explicit ''Device'' statement) tape code as of v2026.08.28 has not yet undergone extensive testing.

=== CD drive support ===
* create directory <code>CD0</code>,
* populate with one or more readymade ISO images,
* use the serial console to attach image(s) to the drive.

No special handling for the ID in ''zuluscsi.ini''.

Caveats:
* When you choose an image file through the USB port's media menu, make sure that you not only choose an image file, but afterwards ''insert'' it!
* If you replace a hardware CD drive, make sure to delete your old CD device file first, then IPL, check/set the new device name in DST, and have auto-configuration create the new device file during the following IPL.

Tested with Firmware 2026-08-07, 9401-150, V4R4, V5R2: IPL only so far, but that works.

=== Disk drive support ===
The officially released code base is able to present multiple disk drives to the system, initialize, and install SLIC + base OS/400 + LPPs + PTFs.

* Copy ''as400_disk_definitions.txt'' from the official GitHub repository to the SD card.
** Because of serial numbers currently being hard coded, only one disk per type should be used for now!
* ''zuluscsi.ini'':
[SCSI]
System = AS400_PPC

[SCSI6]
AS400_DiskProfile = "09L4044"
PrefetchBytes = 0

When a ''AS400_DiskProfile'' is configured for a given SCSI ID, and the associated image cannot be found on the SD card, a new one is generated automatically, with the correct size. This takes some time, so wait until the activity LED stays unlit.

There is a shell-script <code>utils/extract_as400_disk_data.sh</code> in the original source tree on GitHub to generate more ''as400_disk_definitions.txt'' entries from real disks connected to a SCSI controller when ran under Linux.

Caveats:
* Writes to the emulated disk are very slow compared to reads.

Fully tested with Firmware v2026.08.27RC1, 9401-150, V4R4, V5R2.

== Current state ==
We have to differ three hardware generations when considering Zulu vs. AS/400:
{|class="wikitable"
! 
!CISC/IMPI, 520 bytes/block disks
!RISC/SPD, 520/522 bytes/block disks
!RISC/PCI, 522 bytes/block disks
|-
!CD-ROM
|Not supported
|Untested
|Works
|-
!Tape
|Fails, hangs with SRC early.
|Untested
|Works
|-
!Disk
|Fails, hangs with SRC early.
|Untested
|Works
|}

All successful tests so far have been based on a ZuluSCSI wide board on a 9401-150, while the CISC tests have been done with a ZuluSCSI Blaster on a 9401-P02.

There are success reports of more 150's working, and one of a 9406-270 becoming stuck with A6000244, ''Contact was lost with device indicated''.

== See also ==
* [[Ordinary Harddisks on the AS/400]]
* [[Tape Drives on old AS/400]]
* [[SRC]], aka System Reference Code

== Weblinks ==
* [https://zuluscsi.com ZuluSCSI Website] — see the <tt>☰</tt> button top right for more details
* [https://github.com/ZuluSCSI/ZuluSCSI-firmware ZuluSCSI-firmware], GitHub

== Footnotes ==
<references />

[[Category:Hardware Configuration Guide]]

ZuluSCSI

2026-08-29T20:51:58Z

PoC: /* Disk drive support */ Typo

'''ZuluSCSI''' by Rabbit Hole Computing is a comparatively new family of SCSI device emulators featuring an SD card based backing store. Distinct features to older, similar devices is support for Wide-SCSI, Ultra-Speed, and a fast CPU.

ZuluSCSI also features an OpenSource firmware, so it can be extended comparatively easily.

__TOC__

For most AS/400 machines, you actually want a ZuluSCSI wide, because it offers the best performance.

The ZuluSCSI firmware can emulate multiple devices at once. There is no real need to add multiple Zulus to a given SCSI bus. One Zulu can easily saturate even the UltraWide SCSI bus of a 9401-150, and due to the SD card, delays are minimal. You can gain more performance with bigger machines, if they have multiple SCSI buses, though.

<blockquote>'''Note:''' Current state of affairs is that at least for writes, the SD card itself is a considerable brake shoe for writes, presumably because of so called 'Write Amplification''. This is not meant to stay like this forever. Optimizations are possible and will be implemented eventually.</blockquote>

== Hardware overview ==
Depending on the exact model, boards themselves have three DIP switches and tiny push buttons:
* 1: switch to initator mode,
* 2: enable debug log,
* 3: enable SCSI termination.

The push buttons call the functions:
* Bootloader, for firmware-recovery,
* Eject.

Also, three LEDs are provided, for indication of
* 2.8 V power OK,
* 3.3 V power OK,
* SD-card activity.

The device itself needs 5 V power, and can be powered by:
* the USB port,
* the termpower line of the SCSI bus,
* molex style power connectors.

Usually, the integrated USB port is configured as USB modem, for usage with a terminal emulator. You can use the Linux or macOS ''screen'' command for that. Depending on your operating system, you need to find out what device file is created when plugging the Zulu's USB port. On Linux, it's <tt>/dev/ttyACM''n''</tt> — ''n'' being a digit, usually 0. On macOS, it's <tt>/dev/tty.usbmodem*</tt>, with a row of digits appended on behalf of the <tt>*</tt>.

The firmware presents a simple menu driven UI for some tasks.

There is no need to shut down the device itself, it's safe to "pull the plug" when there is no activity. The Operating System running on the attached computer should be orderly shut down, though.

== Configuration ==
Configuration itself is usually automatic, according to the files and directories found on the SD card. The SD card has either a FAT32<ref>Limiting files to max. 4 GiB in size</ref> or exFAT file system, the firmware understands both. It's easier to use the SD card with a card reader on a newer computer to create configurations, and files. The SD card is hotplug capable, and upon reinsertation, the ZuluSCSI reinitializes itself according to the SD card's content.

Three devices classes are of general interest in the AS/400 world:
* Disk (DASD),
* CD/DVD (Optical),
* Tape.

=== Files ===
File names are composed as follows:
<nowiki><TT><ID>[any text].<ext></nowiki>
^^ ^
| +-------------- SCSI ID character (byte offset 2)
+------------------- two-character type prefix (case-insensitive)

* '''TT''':
:{|class="wikitable"
!TT
!Device type
!Default block size
|-
|HD
|Hard disk (fixed)
|align="right"|512 Bytes
|-
|CD
|CD-ROM (optical)
|align="right"|2048 Bytes
|-
|TP
|Sequential (tape)
|align="right"|512 Bytes
|}
* The '''ID''' is exactly one char, and must be given in hexadecimal. This matters only for IDs ≥ 10.
* '''any text''' is entirely optional.
* The '''file extension''' doesn't matter.

=== Directories ===
For a device usually allowing dynamic addition and removal of media — CD-ROM-, and tape drives, you can create a directory instead of a file. The naming scheme follows the same structure as files, but ''[any text]'' must be omitted.

Files within the directories can be freely named. The ''Eject'' button loads and inserts the next image in order. Individual images can be inserted through the menu via USB.

=== Configuration file ===
In addition, a configuration file can be supplied to provide additional information to either all or one emulated device. Having a ''zuluscsi.ini'' is normally optional, but for enabling AS/400 quirks, it's mandatory.

The configuration file must be named ''zuluscsi.ini'', and is in a simple ini-style format. It has a global <tt>[SCSI]</tt> section to apply settings to all devices, and <tt>[SCSI''n'']</tt>, where ''n'' is the ID of the given SCSI devices.

== Examples ==
These are in the scope of AS/400.

=== Tape drive support ===
* create directory <code>TP0</code>,
* populate with one or more 0 byte files named <code>*.tap</code> files, e. g. by using the Unix <code>touch</code>,
* use the serial console to attach image(s) to the drive.
* ''zuluscsi.ini'':
[SCSI]
System="AS400_PPC"

[SCSI0]
Device = "AS400_PPC"

Caveats:
* When you choose an image file through the USB port's media menu, make sure that you not only choose an image file, but afterwards ''insert'' it!
* If you replace a hardware tape drive, make sure to delete your old tape device file first, then IPL, check/set the new device name in DST, and have auto-configuration create the new device file during the following IPL.
* The amended (with an explicit ''Device'' statement) tape code as of v2026.08.28 has not yet undergone extensive testing.

=== CD drive support ===
* create directory <code>CD0</code>,
* populate with one or more readymade ISO images,
* use the serial console to attach image(s) to the drive.

No special handling for the ID in ''zuluscsi.ini''.

Caveats:
* When you choose an image file through the USB port's media menu, make sure that you not only choose an image file, but afterwards ''insert'' it!
* If you replace a hardware CD drive, make sure to delete your old CD device file first, then IPL, check/set the new device name in DST, and have auto-configuration create the new device file during the following IPL.

Tested with Firmware 2026-08-07, 9401-150, V4R4, V5R2: IPL only so far, but that works.

=== Disk drive support ===
The officially released code base is able to present multiple disk drives to the system, initialize, and install SLIC + base OS/400 + LPPs + PTFs.

* Copy ''as400_disk_definitions.txt'' from the official GitHub repository to the SD card.
** Because of serial numbers currently being hard coded, only one disk per type should be used for now!
* ''zuluscsi.ini'':
[SCSI]
System = AS400_PPC

[SCSI6]
AS400_DiskProfile = "09L4044"
PrefetchBytes = 0

When a ''AS400_DiskProfile'' is configured for a given SCSI ID, and the associated image cannot be found on the SD card, a new one is generated automatically, with the correct size. This takes some time, so wait until the activity LED stays unlit.

There is a shell-script <code>utils/extract_as400_disk_data.sh</code> in the original source tree on GitHub to generate more ''as400_disk_definitions.txt'' entries from real disks connected to a SCSI controller when ran under Linux.

Caveats:
* Writes to the emulated disk are very slow compared to reads.

Fully tested with Firmware v2026.08.27RC1, 9401-150, V4R4, V5R2.

== Current state ==
We have to differ three hardware generations when considering Zulu vs. AS/400:
{|class="wikitable"
! 
!CISC/IMPI, 520 bytes/block disks
!RISC/SPD, 520/522 bytes/block disks
!RISC/PCI, 522 bytes/block disks
|-
!CD-ROM
|Not supported
|Untested
|Works
|-
!Tape
|Fails, hangs with SRC early.
|Untested
|Works
|-
!Disk
|Fails, hangs with SRC early.
|Untested
|Works
|}

All successful tests so far have been based on a ZuluSCSI wide board on a 9401-150, while the CISC tests have been done with a ZuluSCSI Blaster on a 9401-P02.

There are success reports of more 150's working, and one of a 9406-270 becoming stuck with A6000244, ''Contact was lost with device indicated''.

== See also ==
* [[Ordinary Harddisks on the AS/400]]
* [[Tape Drives on old AS/400]]
* [[SRC]], aka System Reference Code

== Weblinks ==
* [https://zuluscsi.com ZuluSCSI Website] — see the <tt>☰</tt> button top right for more details
* [https://github.com/ZuluSCSI/ZuluSCSI-firmware ZuluSCSI-firmware], GitHub

== Footnotes ==
<references />

[[Category:Hardware Configuration Guide]]

ZuluSCSI

2026-08-29T20:51:30Z

PoC: Reworked after release

'''ZuluSCSI''' by Rabbit Hole Computing is a comparatively new family of SCSI device emulators featuring an SD card based backing store. Distinct features to older, similar devices is support for Wide-SCSI, Ultra-Speed, and a fast CPU.

ZuluSCSI also features an OpenSource firmware, so it can be extended comparatively easily.

__TOC__

For most AS/400 machines, you actually want a ZuluSCSI wide, because it offers the best performance.

The ZuluSCSI firmware can emulate multiple devices at once. There is no real need to add multiple Zulus to a given SCSI bus. One Zulu can easily saturate even the UltraWide SCSI bus of a 9401-150, and due to the SD card, delays are minimal. You can gain more performance with bigger machines, if they have multiple SCSI buses, though.

<blockquote>'''Note:''' Current state of affairs is that at least for writes, the SD card itself is a considerable brake shoe for writes, presumably because of so called 'Write Amplification''. This is not meant to stay like this forever. Optimizations are possible and will be implemented eventually.</blockquote>

== Hardware overview ==
Depending on the exact model, boards themselves have three DIP switches and tiny push buttons:
* 1: switch to initator mode,
* 2: enable debug log,
* 3: enable SCSI termination.

The push buttons call the functions:
* Bootloader, for firmware-recovery,
* Eject.

Also, three LEDs are provided, for indication of
* 2.8 V power OK,
* 3.3 V power OK,
* SD-card activity.

The device itself needs 5 V power, and can be powered by:
* the USB port,
* the termpower line of the SCSI bus,
* molex style power connectors.

Usually, the integrated USB port is configured as USB modem, for usage with a terminal emulator. You can use the Linux or macOS ''screen'' command for that. Depending on your operating system, you need to find out what device file is created when plugging the Zulu's USB port. On Linux, it's <tt>/dev/ttyACM''n''</tt> — ''n'' being a digit, usually 0. On macOS, it's <tt>/dev/tty.usbmodem*</tt>, with a row of digits appended on behalf of the <tt>*</tt>.

The firmware presents a simple menu driven UI for some tasks.

There is no need to shut down the device itself, it's safe to "pull the plug" when there is no activity. The Operating System running on the attached computer should be orderly shut down, though.

== Configuration ==
Configuration itself is usually automatic, according to the files and directories found on the SD card. The SD card has either a FAT32<ref>Limiting files to max. 4 GiB in size</ref> or exFAT file system, the firmware understands both. It's easier to use the SD card with a card reader on a newer computer to create configurations, and files. The SD card is hotplug capable, and upon reinsertation, the ZuluSCSI reinitializes itself according to the SD card's content.

Three devices classes are of general interest in the AS/400 world:
* Disk (DASD),
* CD/DVD (Optical),
* Tape.

=== Files ===
File names are composed as follows:
<nowiki><TT><ID>[any text].<ext></nowiki>
^^ ^
| +-------------- SCSI ID character (byte offset 2)
+------------------- two-character type prefix (case-insensitive)

* '''TT''':
:{|class="wikitable"
!TT
!Device type
!Default block size
|-
|HD
|Hard disk (fixed)
|align="right"|512 Bytes
|-
|CD
|CD-ROM (optical)
|align="right"|2048 Bytes
|-
|TP
|Sequential (tape)
|align="right"|512 Bytes
|}
* The '''ID''' is exactly one char, and must be given in hexadecimal. This matters only for IDs ≥ 10.
* '''any text''' is entirely optional.
* The '''file extension''' doesn't matter.

=== Directories ===
For a device usually allowing dynamic addition and removal of media — CD-ROM-, and tape drives, you can create a directory instead of a file. The naming scheme follows the same structure as files, but ''[any text]'' must be omitted.

Files within the directories can be freely named. The ''Eject'' button loads and inserts the next image in order. Individual images can be inserted through the menu via USB.

=== Configuration file ===
In addition, a configuration file can be supplied to provide additional information to either all or one emulated device. Having a ''zuluscsi.ini'' is normally optional, but for enabling AS/400 quirks, it's mandatory.

The configuration file must be named ''zuluscsi.ini'', and is in a simple ini-style format. It has a global <tt>[SCSI]</tt> section to apply settings to all devices, and <tt>[SCSI''n'']</tt>, where ''n'' is the ID of the given SCSI devices.

== Examples ==
These are in the scope of AS/400.

=== Tape drive support ===
* create directory <code>TP0</code>,
* populate with one or more 0 byte files named <code>*.tap</code> files, e. g. by using the Unix <code>touch</code>,
* use the serial console to attach image(s) to the drive.
* ''zuluscsi.ini'':
[SCSI]
System="AS400_PPC"

[SCSI0]
Device = "AS400_PPC"

Caveats:
* When you choose an image file through the USB port's media menu, make sure that you not only choose an image file, but afterwards ''insert'' it!
* If you replace a hardware tape drive, make sure to delete your old tape device file first, then IPL, check/set the new device name in DST, and have auto-configuration create the new device file during the following IPL.
* The amended (with an explicit ''Device'' statement) tape code as of v2026.08.28 has not yet undergone extensive testing.

=== CD drive support ===
* create directory <code>CD0</code>,
* populate with one or more readymade ISO images,
* use the serial console to attach image(s) to the drive.

No special handling for the ID in ''zuluscsi.ini''.

Caveats:
* When you choose an image file through the USB port's media menu, make sure that you not only choose an image file, but afterwards ''insert'' it!
* If you replace a hardware CD drive, make sure to delete your old CD device file first, then IPL, check/set the new device name in DST, and have auto-configuration create the new device file during the following IPL.

Tested with Firmware 2026-08-07, 9401-150, V4R4, V5R2: IPL only so far, but that works.

=== Disk drive support ===
The officially released code base is able to present multiple disk drives to the system, initialize, and install SLIC + base OS/400 + LPPs + PTFs.

* Copy ''as400_disk_definitions.txt'' from the official GitHub repository to the SD card.
** Because of serial numbers currently being hard coded, only one disk per type should be used for now!
* ''zuluscsi.ini'':
[SCSI]
System = AS400_PPC

[SCSI6]
AS400_DiskProfile = "09L4044"
PrefetchBytes = 0

When a ''AS400_DiskProfile'' is configured for a given SCSI ID, and the associated image cannot be found on the SD card, a new one is generated automatically, with the correct size. This takes some time, so wait until the activity LED stays unlit.

There is a shell-script <code>utils/extract_as400_disk_data.sh</code> in the original source tree on GitHub to generate more ''as400_disk_definitions.txt'' entries from real disks connected to a SCSI controller when ran under Linux.

Caveats:
* Writes to the emulated disk are very slow compared to reads.

Fully tested with Firmware v2026.08.27RC1, 9401-150, V4R4, V5R2.

== Current state ==
We have to differ three hardware generations when considering Zulu vs. AS/400:
{|class="wikitable"
! 
!CISC/IMPI, 520 bytes/block disks
!RISC/SPD, 520/522 bytes/block disks
!RISC/PCI, 522 bytes/block disks
|-
!CD-ROM
|Not supported
|Untested
|Works
|-
!Tape
|Fails, hangs with SRC early.
|Untested
|Works
|-
!Disk
|Fails, hangs with SRC early.
|Untested
|Works
|}

All successful tests so far have been based on a ZuluSCSI wide board on a 9401-150, while the CISC tests have been done with a ZuluSCSI Blaster on a 9401-P02.

There are success reports of more 150's working, and one of a 9406-270 becoming stuck with A6000244, ''Contact was lost with device indicated''.

== See also ==
* [[Ordinary Harddisks on the AS/400]]
* [[Tape Drives on old AS/400]]
* [[SRC]], aka System Reference Code

== Weblinks ==
* [https://zuluscsi.com ZuluSCSI Website] — see the <tt>☰</tt> button top right for more details
* [https://github.com/ZuluSCSI/ZuluSCSI-firmware ZuluSCSI-firmware], GitHub

== Footnotes ==
<references />

[[Category:Hardware Configuration Guide]]

ZuluSCSI

2026-08-29T19:54:09Z

PoC: Reworked

'''ZuluSCSI''' by Rabbit Hole Computing is a comparatively new family of SCSI device emulators featuring an SD card based backing store. Distinct features to older, similar devices is support for Wide-SCSI, Ultra-Speed, and a fast CPU.

ZuluSCSI also features an OpenSource firmware, so it can be extended comparatively easily.

__TOC__

For most AS/400 machines, you actually want a ZuluSCSI wide, because it offers the best performance.

The ZuluSCSI firmware can emulate multiple devices at once. There is no real need to add multiple Zulus to a given SCSI bus. One Zulu can easily saturate even the UltraWide SCSI bus of a 9401-150, and due to the SD card, delays are minimal. You can gain more performance with bigger machines, if they have multiple SCSI buses, though.

<blockquote>'''Note:''' Current state of affairs is that at least for writes, the SD card itself is a considerable brake shoe for writes, presumably because of so called 'Write Amplification''. This is not meant to stay like this forever. Optimizations are possible and will be implemented eventually.</blockquote>

== Hardware overview ==
Depending on the exact model, boards themselves have three DIP switches and tiny push buttons:
* 1: switch to initator mode,
* 2: enable debug log,
* 3: enable SCSI termination.

The push buttons call the functions:
* Bootloader, for firmware-recovery,
* Eject.

Also, three LEDs are provided, for indication of
* 2.8 V power OK,
* 3.3 V power OK,
* SD-card activity.

The device itself needs 5 V power, and can be powered by:
* the USB port,
* the termpower line of the SCSI bus,
* molex style power connectors.

Usually, the integrated USB port is configured as USB modem, for usage with a terminal emulator. You can use the Linux or macOS ''screen'' command for that. Depending on your operating system, you need to find out what device file is created when plugging the Zulu's USB port. On Linux, it's <tt>/dev/ttyACM''n''</tt> — ''n'' being a digit, usually 0. On macOS, it's <tt>/dev/tty.usbmodem*</tt>, with a row of digits appended on behalf of the <tt>*</tt>.

The firmware presents a simple menu driven UI for some tasks.

There is no need to shut down the device itself, it's safe to "pull the plug" when there is no activity. The Operating System running on the attached computer should be orderly shut down, though.

== Configuration ==
Configuration itself is usually automatic, according to the files and directories found on the SD card. The SD card has either a FAT32<ref>Limiting files to max. 4 GiB in size</ref> or exFAT file system, the firmware understands both. It's easier to use the SD card with a card reader on a newer computer to create configurations, and files. The SD card is hotplug capable, and upon reinsertation, the ZuluSCSI reinitializes itself according to the SD card's content.

Three devices classes are of general interest in the AS/400 world:
* Disk (DASD),
* CD/DVD (Optical),
* Tape.

=== Files ===
File names are composed as follows:
<nowiki><TT><ID>[any text].<ext></nowiki>
^^ ^
| +-------------- SCSI ID character (byte offset 2)
+------------------- two-character type prefix (case-insensitive)

* '''TT''':
:{|class="wikitable"
!TT
!Device type
!Default block size
|-
|HD
|Hard disk (fixed)
|align="right"|512 Bytes
|-
|CD
|CD-ROM (optical)
|align="right"|2048 Bytes
|-
|TP
|Sequential (tape)
|align="right"|512 Bytes
|}
* The '''ID''' is exactly one char, and must be given in hexadecimal. This matters only for IDs ≥ 10.
* '''any text''' is entirely optional.
* The '''file extension''' doesn't matter.

=== Directories ===
For a device usually allowing dynamic addition and removal of media — CD-ROM-, and tape drives, you can create a directory instead of a file. The naming scheme follows the same structure as files, but ''[any text]'' must be omitted.

Files within the directories can be freely named. The ''Eject'' button loads and inserts the next image in order. Individual images can be inserted through the menu via USB.

=== Configuration file ===
In addition, a configuration file can be supplied to provide additional information to either all or one emulated device. Having a ''zuluscsi.ini'' is normally optional, but for enabling AS/400 quirks, it's mandatory.

The configuration file must be named ''zuluscsi.ini'', and is in a simple ini-style format. It has a global <tt>[SCSI]</tt> section to apply settings to all devices, and <tt>[SCSI''n'']</tt>, where ''n'' is the ID of the given SCSI devices.

== Examples ==
These are in the scope of AS/400.

=== Tape drive support ===
* create directory <code>TP0</code>,
* populate with one or more 0 byte files named <code>*.tap</code> files, e. g. by using the Unix <code>touch</code>,
* use the serial console to attach image(s) to the drive.
* ''zuluscsi.ini'':
[SCSI]
System="AS400_PPC"

[SCSI0]
TapeDensity = 0x25

Caveats:
* When you choose an image file through the USB port's media menu, make sure that you not only choose an image file, but afterwards ''insert'' it!
* If you replace a hardware tape drive, make sure to delete your old tape device file first, then IPL, check/set the new device name in DST, and have auto-configuration create the new device file during the following IPL.

This configuration has been tested over the course of multiple weeks:
* Occasional <tt>go save</tt> 21,
* daily differential backups,
* occasional single file restores.

Tested with Firmware 2026-06-12, 9401-150, V4R5.

=== CD drive support ===
* create directory <code>CD0</code>,
* populate with one or more readymade ISO images,
* use the serial console to attach image(s) to the drive.

No special handling for the ID in ''zuluscsi.ini''.

Caveats:
* When you choose an image file through the USB port's media menu, make sure that you not only choose an image file, but afterwards ''insert'' it!
* If you replace a hardware CD drive, make sure to delete your old CD device file first, then IPL, check/set the new device name in DST, and have auto-configuration create the new device file during the following IPL.

Tested with Firmware 2026-08-07, 9401-150, V4R4: IPL only so far.

=== Disk drive support ===
The officially released code base is able to present a singular #6717, 8.5 GiB disk drive to the system, initialize, and install SLIC + base OS/400 + LPPs + PTFs.

* Generate disk image:
dd if=/dev/zero of=HD6.img bs=522 count=17177940 status=progress
* ''zuluscsi.ini'':
[SCSI]
System = AS400_PPC

[SCSI6]
PrefetchBytes = 0

Caveats:
* Writes to the emulated disk are very slow compared to reads.
* One user with a RP2040 reported failure for the disk to be recognized. Prerelease firmware solved the issue.

Fully tested with Firmware 2026-08-21, 9401-150, V4R4, V5R2.

== Current state ==
We have to differ three hardware generations when considering Zulu vs. AS/400:
{|class="wikitable"
! 
!CISC/IMPI, 520 bytes/block disks
!RISC/SPD, 520/522 bytes/block disks
!RISC/PCI, 522 bytes/block disks
|-
!CD-ROM
|Not supported
|Untested
|Works
|-
!Tape
|Fails, hangs with SRC early.
|Untested
|Works
|-
!Disk
|Fails, hangs with SRC early.
|Untested
|Works
|}

All successful tests so far have been based on a ZuluSCSI wide board on a 9401-150, while the CISC tests have been done with a ZuluSCSI Blaster on a 9401-P02.

There are success reports of more 150's working, and one of a 9406-270 becoming stuck with A6000244, ''Contact was lost with device indicated''.

== Next ==
These features are completed, partially tested, but did not make it to the official releases yet:
* More disk profiles, loadable in ''zuluscsi.ini'' via external file ''as400_disk_definitions.txt'', so different types than the built-in 522 bytes, 8.5 GiB #6717 can be assigned.
** Shellscript to generate more ''as400_disk_definitions.txt'' entries from real disks connected to a SCSI controller when ran under Linux
** Because of serial numbers currently being hard coded, only one disk per type should be used
* Allowed more memory to accommodate the necessary VPD SCSI pages for multiple disks
* Present captured real tape VPD/SCSI data from IBM SLR5/QIC1000 when using <code>Device = "AS400_PPC"</code> or <code>Device = "AS400_CISC"</code> in an ID stanza

== See also ==
* [[Ordinary Harddisks on the AS/400]]
* [[Tape Drives on old AS/400]]
* [[SRC]], aka System Reference Code

== Weblinks ==
* [https://zuluscsi.com ZuluSCSI Website] — see the <tt>☰</tt> button top right for more details
* [https://github.com/ZuluSCSI/ZuluSCSI-firmware ZuluSCSI-firmware], GitHub

== Footnotes ==
<references />

[[Category:Hardware Configuration Guide]]

ZuluSCSI

2026-08-28T08:01:13Z

PoC: /* Current state */ updates

'''ZuluSCSI''' by Rabbit Hole Computing is a comparatively new family of SCSI device emulators featuring an SD card based backing store. Distinct features to older, similar devices is support for Wide-SCSI, Ultra-Speed, and a fast CPU.

ZuluSCSI also features an OpenSource firmware, so it can be extended comparatively easily.

__TOC__

For most AS/400 machines, you actually want a ZuluSCSI wide, because it offers the best performance.

The ZuluSCSI firmware can emulate multiple devices at once. There is no real need to add multiple Zulus to a given SCSI bus. One Zulu can easily saturate even the UltraWide SCSI bus of a 9401-150, and due to the SD card, delays are minimal. You can gain more performance with bigger machines, if they have multiple SCSI buses, though.

== Hardware overview ==
Depending on the exact model, boards themselves have three DIP switches and tiny push buttons:
* 1: switch to initator mode,
* 2: enable debug log,
* 3: enable SCSI termination.

The push buttons call the functions:
* Bootloader, for firmware-recovery,
* Eject.

Also, three LEDs are provided, for indication of
* 2.8 V power OK,
* 3.3 V power OK,
* SD-card activity.

The device itself needs 5 V power, and can be powered by:
* the USB port,
* the termpower line of the SCSI bus,
* molex style power connectors.

Usually, the integrated USB port is configured as USB modem, for usage with a terminal emulator. You can use the Linux or macOS ''screen'' command for that. Depending on your operating system, you need to find out what device file is created when plugging the Zulu's USB port. On Linux, it's <tt>/dev/ttyACM''n''</tt> — ''n'' being a digit, usually 0. On macOS, it's <tt>/dev/tty.usbmodem*</tt>, with a row of digits appended on behalf of the <tt>*</tt>.

The firmware presents a simple menu driven UI for some tasks.

There is no need to shut down the device itself, it's safe to "pull the plug" when there is no activity. The Operating System running on the attached computer should, though.

== Configuration ==
Configuration itself is usually automatic, according to the files and directories found on the SD card. The SD card has either a FAT32<ref>Limiting files to max. 4 GiB in size</ref> or exFAT file system, the firmware understands both. It's easier to use the SD card with a card reader on a newer computer to create configurations, and files. The SD card is hotplug capable, and upon reinsertation, the ZuluSCSI reinitializes itself according to the SD card's content.

Three devices classes are of general interest in the AS/400 world:
* Disk (DASD),
* CD/DVD (Optical),
* Tape.

=== Files ===
File names are composed as follows:
<nowiki><TT><ID>[any text].<ext></nowiki>
^^ ^
| +-------------- SCSI ID character (byte offset 2)
+------------------- two-character type prefix (case-insensitive)

* '''TT''':
:{|class="wikitable"
!TT
!Device type
!Default block size
|-
|HD
|Hard disk (fixed)
|align="right"|512 Bytes
|-
|CD
|CD-ROM (optical)
|align="right"|2048 Bytes
|-
|TP
|Sequential (tape)
|align="right"|512 Bytes
|}
* The '''ID''' is exactly one char, and must be given in hexadecimal. This matters only for IDs ≥ 10.
* '''any text''' is entirely optional.
* The '''file extension''' doesn't matter.

=== Directories ===
For a device usually allowing dynamic addition and removal of media — CD-ROM-, and tape drives. The naming scheme follows the same structure as files, but ''[any text]'' must be omitted.

Files within the directories can be freely named, and are used in alphabetical order.<ref>Either through the ''Eject'' button, or the media menu.</ref>

=== Configuration file ===
In addition, a configuration file can be supplied to provide additional information to either all or one emulated device. Having a ''zuluscsi.ini'' is normally optional, but for enabling AS/400 quirks, it's mandatory.

The configuration file must be named ''zuluscsi.ini'', and is in a simple ini-style format. It has a global <tt>[SCSI]</tt> section to apply settings to all devices, and <tt>[SCSI''n'']</tt>, where ''n'' is the ID of the given SCSI devices.

== Examples ==
These are in the scope of AS/400.

=== Tape drive support ===
* create directory <code>TP0</code>,
* populate with one or more 0 byte files named <code>*.tap</code> files, e. g. by using the Unix <code>touch</code>,
* use the serial console to attach image(s) to the drive.
* ''zuluscsi.ini'':
[SCSI]
System="AS400_PPC"

[SCSI0]
TapeDensity = 0x25

Caveats:
* When you choose an image file through the USB port's media menu, make sure that you not only choose an image file, but afterwards ''insert'' it!
* If you replace a hardware tape drive, make sure to delete your old tape device file first, then IPL, check/set the new device name in DST, and have auto-configuration create the new device file during the following IPL.

This configuration has been tested over the course of multiple weeks:
* Occasional <tt>go save</tt> 21,
* daily differential backups,
* occasional single file restores.

Tested with Firmware 2026-06-12, 9401-150, V4R5.

=== CD drive support ===
* create directory <code>CD0</code>,
* populate with one or more readymade ISO images,
* use the serial console to attach image(s) to the drive.

No special handling for the ID in ''zuluscsi.ini''.

Caveats:
* When you choose an image file through the USB port's media menu, make sure that you not only choose an image file, but afterwards ''insert'' it!
* If you replace a hardware CD drive, make sure to delete your old CD device file first, then IPL, check/set the new device name in DST, and have auto-configuration create the new device file during the following IPL.

Tested with Firmware 2026-08-07, 9401-150, V4R4: IPL only so far.

=== Disk drive support ===
The officially released code base is able to present a singular #6717, 8.5 GiB disk drive to the system, initialize, and install SLIC + base OS/400 + LPPs + PTFs.

* Generate disk image:
dd if=/dev/zero of=HD6.img bs=522 count=17177940 status=progress
* ''zuluscsi.ini'':
[SCSI]
System = AS400_PPC

[SCSI6]
PrefetchBytes = 0

Caveats:
* Writes to the emulated disk are very slow compared to reads.
* One user with a RP2040 reported failure for the disk to be recognized. Prerelease firmware solved the issue.

Fully tested with Firmware 2026-08-21, 9401-150, V4R4.

== Current state ==
We have to differ three hardware generations when considering Zulu vs. AS/400:
{|class="wikitable"
! 
!CISC/IMPI, 520 bytes/block disks
!RISC/SPD, 520/522 bytes/block disks
!RISC/PCI, 522 bytes/block disks
|-
!CD-ROM
|Not supported
|Untested
|Works
|-
!Tape
|Fails, hangs with SRC early.
|Untested
|Works
|-
!Disk
|Fails, hangs with SRC early.
|Untested
|Works
|}

All successful tests so far have been based on a ZuluSCSI wide board on a 9401-150, while the CISC tests have been done with a ZuluSCSI Blaster on a 9401-P02.

There are success reports of more 150's working, and one of a 9406-270 becoming stuck with A6000244, ''Contact was lost with device indicated''.

== Next ==
These features are completed, partially tested, but did not make it to the official releases yet:
* More disk profiles, loadable in ''zuluscsi.ini'' via external file ''as400_disk_definitions.txt'', so different types than the built-in 522 bytes, 8.5 GiB #6717 can be assigned.
** Shellscript to generate more ''as400_disk_definitions.txt'' entries from real disks connected to a SCSI controller when ran under Linux
** Because of serial numbers currently being hard coded, only one disk per type should be used
* Allowed more memory to accommodate the necessary VPD SCSI pages for multiple disks
* Present captured real tape VPD/SCSI data from IBM SLR5/QIC1000 when using <code>Device = "AS400_PPC"</code> or <code>Device = "AS400_CISC"</code> in an ID stanza

Currently contained in v2026.08.27-RC1.

== See also ==
* [[Ordinary Harddisks on the AS/400]]
* [[Tape Drives on old AS/400]]
* [[SRC]], aka System Reference Code

== Weblinks ==
* [https://zuluscsi.com ZuluSCSI Website] — see the <tt>☰</tt> button top right for more details
* [https://github.com/ZuluSCSI/ZuluSCSI-firmware ZuluSCSI-firmware], GitHub

== Footnotes ==
<references />

[[Category:Hardware Configuration Guide]]

ZuluSCSI

2026-08-28T07:39:26Z

PoC: /* Next */ Updated things

'''ZuluSCSI''' by Rabbit Hole Computing is a comparatively new family of SCSI device emulators featuring an SD card based backing store. Distinct features to older, similar devices is support for Wide-SCSI, Ultra-Speed, and a fast CPU.

ZuluSCSI also features an OpenSource firmware, so it can be extended comparatively easily.

__TOC__

For most AS/400 machines, you actually want a ZuluSCSI wide, because it offers the best performance.

The ZuluSCSI firmware can emulate multiple devices at once. There is no real need to add multiple Zulus to a given SCSI bus. One Zulu can easily saturate even the UltraWide SCSI bus of a 9401-150, and due to the SD card, delays are minimal. You can gain more performance with bigger machines, if they have multiple SCSI buses, though.

== Hardware overview ==
Depending on the exact model, boards themselves have three DIP switches and tiny push buttons:
* 1: switch to initator mode,
* 2: enable debug log,
* 3: enable SCSI termination.

The push buttons call the functions:
* Bootloader, for firmware-recovery,
* Eject.

Also, three LEDs are provided, for indication of
* 2.8 V power OK,
* 3.3 V power OK,
* SD-card activity.

The device itself needs 5 V power, and can be powered by:
* the USB port,
* the termpower line of the SCSI bus,
* molex style power connectors.

Usually, the integrated USB port is configured as USB modem, for usage with a terminal emulator. You can use the Linux or macOS ''screen'' command for that. Depending on your operating system, you need to find out what device file is created when plugging the Zulu's USB port. On Linux, it's <tt>/dev/ttyACM''n''</tt> — ''n'' being a digit, usually 0. On macOS, it's <tt>/dev/tty.usbmodem*</tt>, with a row of digits appended on behalf of the <tt>*</tt>.

The firmware presents a simple menu driven UI for some tasks.

There is no need to shut down the device itself, it's safe to "pull the plug" when there is no activity. The Operating System running on the attached computer should, though.

== Configuration ==
Configuration itself is usually automatic, according to the files and directories found on the SD card. The SD card has either a FAT32<ref>Limiting files to max. 4 GiB in size</ref> or exFAT file system, the firmware understands both. It's easier to use the SD card with a card reader on a newer computer to create configurations, and files. The SD card is hotplug capable, and upon reinsertation, the ZuluSCSI reinitializes itself according to the SD card's content.

Three devices classes are of general interest in the AS/400 world:
* Disk (DASD),
* CD/DVD (Optical),
* Tape.

=== Files ===
File names are composed as follows:
<nowiki><TT><ID>[any text].<ext></nowiki>
^^ ^
| +-------------- SCSI ID character (byte offset 2)
+------------------- two-character type prefix (case-insensitive)

* '''TT''':
:{|class="wikitable"
!TT
!Device type
!Default block size
|-
|HD
|Hard disk (fixed)
|align="right"|512 Bytes
|-
|CD
|CD-ROM (optical)
|align="right"|2048 Bytes
|-
|TP
|Sequential (tape)
|align="right"|512 Bytes
|}
* The '''ID''' is exactly one char, and must be given in hexadecimal. This matters only for IDs ≥ 10.
* '''any text''' is entirely optional.
* The '''file extension''' doesn't matter.

=== Directories ===
For a device usually allowing dynamic addition and removal of media — CD-ROM-, and tape drives. The naming scheme follows the same structure as files, but ''[any text]'' must be omitted.

Files within the directories can be freely named, and are used in alphabetical order.<ref>Either through the ''Eject'' button, or the media menu.</ref>

=== Configuration file ===
In addition, a configuration file can be supplied to provide additional information to either all or one emulated device. Having a ''zuluscsi.ini'' is normally optional, but for enabling AS/400 quirks, it's mandatory.

The configuration file must be named ''zuluscsi.ini'', and is in a simple ini-style format. It has a global <tt>[SCSI]</tt> section to apply settings to all devices, and <tt>[SCSI''n'']</tt>, where ''n'' is the ID of the given SCSI devices.

== Examples ==
These are in the scope of AS/400.

=== Tape drive support ===
* create directory <code>TP0</code>,
* populate with one or more 0 byte files named <code>*.tap</code> files, e. g. by using the Unix <code>touch</code>,
* use the serial console to attach image(s) to the drive.
* ''zuluscsi.ini'':
[SCSI]
System="AS400_PPC"

[SCSI0]
TapeDensity = 0x25

Caveats:
* When you choose an image file through the USB port's media menu, make sure that you not only choose an image file, but afterwards ''insert'' it!
* If you replace a hardware tape drive, make sure to delete your old tape device file first, then IPL, check/set the new device name in DST, and have auto-configuration create the new device file during the following IPL.

This configuration has been tested over the course of multiple weeks:
* Occasional <tt>go save</tt> 21,
* daily differential backups,
* occasional single file restores.

Tested with Firmware 2026-06-12, 9401-150, V4R5.

=== CD drive support ===
* create directory <code>CD0</code>,
* populate with one or more readymade ISO images,
* use the serial console to attach image(s) to the drive.

No special handling for the ID in ''zuluscsi.ini''.

Caveats:
* When you choose an image file through the USB port's media menu, make sure that you not only choose an image file, but afterwards ''insert'' it!
* If you replace a hardware CD drive, make sure to delete your old CD device file first, then IPL, check/set the new device name in DST, and have auto-configuration create the new device file during the following IPL.

Tested with Firmware 2026-08-07, 9401-150, V4R4: IPL only so far.

=== Disk drive support ===
The officially released code base is able to present a singular #6717, 8.5 GiB disk drive to the system, initialize, and install SLIC + base OS/400 + LPPs + PTFs.

* Generate disk image:
dd if=/dev/zero of=HD6.img bs=522 count=17177940 status=progress
* ''zuluscsi.ini'':
[SCSI]
System = AS400_PPC

[SCSI6]
PrefetchBytes = 0

Caveats:
* Writes to the emulated disk are very slow compared to reads.
* One user with a RP2040 reported failure for the disk to be recognized. Prerelease firmware solved the issue.

Fully tested with Firmware 2026-08-21, 9401-150, V4R4.

== Current state ==
We have to differ three hardware generations when considering Zulu vs. AS/400:
{|class="wikitable"
! 
!CISC/IMPI, 520 bytes/block disks
!RISC/SPD, 520/522 bytes/block disks
!RISC/PCI, 522 bytes/block disks
|-
!CD-ROM
|Not supported
|Untested
|Works
|-
!Tape
|Fails, hangs with SRC early.
|Untested
|Works
|-
!Disk
|Fails, hangs with SRC early.
|Untested
|Works
|}

All successful tests so far have been based on a ZuluSCSI wide board, while the CISC tests have been done with a ZuluSCSI Blaster.

== Next ==
These features are completed, partially tested, but did not make it to the official releases yet:
* More disk profiles, loadable in ''zuluscsi.ini'' via external file ''as400_disk_definitions.txt'', so different types than the built-in 522 bytes, 8.5 GiB #6717 can be assigned.
** Shellscript to generate more ''as400_disk_definitions.txt'' entries from real disks connected to a SCSI controller when ran under Linux
** Because of serial numbers currently being hard coded, only one disk per type should be used
* Allowed more memory to accommodate the necessary VPD SCSI pages for multiple disks
* Present captured real tape VPD/SCSI data from IBM SLR5/QIC1000 when using <code>Device = "AS400_PPC"</code> or <code>Device = "AS400_CISC"</code> in an ID stanza

Currently contained in v2026.08.27-RC1.

== See also ==
* [[Ordinary Harddisks on the AS/400]]
* [[Tape Drives on old AS/400]]
* [[SRC]], aka System Reference Code

== Weblinks ==
* [https://zuluscsi.com ZuluSCSI Website] — see the <tt>☰</tt> button top right for more details
* [https://github.com/ZuluSCSI/ZuluSCSI-firmware ZuluSCSI-firmware], GitHub

== Footnotes ==
<references />

[[Category:Hardware Configuration Guide]]

Serial networking scenarios with Cisco-Routers

2026-08-25T21:17:59Z

PoC: /* Configuration: OS/400 (Fiona) */ Fixed inconsistency

Sometimes, older, donated hardware comes without LAN I/O-adapters. Sometimes it has serial, synchronous capable communication I/O-adapters, though. This article shows several ways how to "network" AS/400 machines through these, with the help of (older) Cisco hard- and software, and points out pros and cons.

<blockquote>'''Note:''' This article is probably more about Cisco configuration than AS/400.</blockquote>

Cisco has provided a lot of configuration options to support different networking scenarios. Emphasis is to multiplex once separated IBM SNA and PC-/Workstation based traffic onto the same physical wiring. Expectably, huge cost savings for recurring bills resulted, because expensive leased lines could now be shared. 
Decades later, the focus shifted from commercial applications to hobbyist uses, with their own set of use cases.

Technologies exploited for the desired outcomes are:
* SDLC as transport protocol for SNA,
* X.25 as transport protocol for higher-level protocols (SNA, IP),
* Data Link Switching Plus (DLSw+) for transport of SNA over IP based links,
* Local or remote media conversion between LANs and SDLC or QLLC (X.25).

This article does intentionally not cover SNASw, a reduced SNA "routing" stack within Cisco IOS. Depending on use case, it has proven to be awfully slow, may even crash routers in some scenarios, and may be of limited use because it's configuration is fixed as a Branch Extender (BEX) node.

For clarity, the scenarios mentioned later always refer to two machines:
* An existing AS/400 with LAN attachment (Token Ring, Ethernet), already established as APPN Network Node in the local LAN. This is the 9401-150 shown on the network plan's right side. This machine's name is ''Nibbler''.
* An additional machine with no LAN I/O adapters, which is meant to establish a network connection of sorts to the existing AS/400. This is the 9401-P03 shown on the network plan's left side. This machine's Name is ''Fiona''.

Additional information is provided in the individual scenario descriptions.

== Physical Layer Requirements ==
[[File:IBM 2652.jpg|thumb|right|#6152 serial IOA (SPD), located in a P02]]
[[File:IBM 2609.jpg|thumb|right|#2609 serial IOA (SPD), located in a P03]]
[[File:IBM 2609 Brick.jpg|thumb|right|2609 Breakout-Brick — note that the Cisco cable is plugged directly which is '''wrong''', and only shown for illustrational purposes.]]
[[File:IBM-2720-Base-PCI-WAN-Twinaxial-IOA.jpg|thumb|right|IBM #2720 combined twinax- and serial IOA (PCI)]]
[[File:IBM-2721-PCI-Two-Line-WAN-IOA.jpg|thumb|right|IBM #2721 dual serial IOA (PCI)]]

On the physical layer, some kind of serial connection is required. In earlier times, AS/400's often had an external modem, providing remote diagnostics capabilities through ''ECS'' (Electronic Customer Support), connected to a serial port. For the sake of simplicity, the AS/400 in question is assumed to already have a serial port, RS-232 style.

<blockquote>'''Note:''' DE-9 or DB-25 connectors directly screwed to the chassis are meant for diagnostics and UPS connection. These are '''not''' normal serial ports!</blockquote>

Matching IBM V.24 Modem Cables for your particular hardware can be sourced e. g. through shops on the internet.

'''Cable designations:'''
{|class="wikitable"
!Description
!Length
!Part Number
!Feature Code
|-
|valign="top"|RS232 Cable DB-25F to DB-25M
|valign="top" rowspan="6"|6.1 m
|valign="top"|22F0149
|valign="top" rowspan="3"|#9022
|-
|valign="top"|(Germany)
|valign="top"|22F0150
|-
|valign="top"|(Japan)
|valign="top"|22F0151
|-
|valign="top"|RS232 PCI Communications Cable Mini-Centronics to DB-25M
|valign="top"|44H7480
|valign="top" rowspan="3"|#0348
|-
|valign="top"|(Germany)
|valign="top"| 44H7482
|-
|valign="top"|(Japan)
|valign="top"| 44H7484
|}

There are other serial connectivity options but these are very rare.

On the Cisco-side of affairs, just two things are necessary:
* Cisco 16xx, 25xx, 26xx or similar router model with T-Type serial interface (card),
* Cisco CAB-232 FC.

<blockquote>'''Note!''' It is of utmost importance to keep in mind that the AS/400 serial ports have ''sense pins'', to know which kind of cable is attached. If you plug in an ordinary PC serial cable, and vary on the line description, you’ll eventually find the succinct message in the QSYSOPR message queue, that a cable could not be found. Therefore the requirement of an ''IBM V.24 Modem Cable'', or a self made cable, or adapter, providing the necessary sense pin connectivity.

'''For this reason, you'll need to plug the DB-25F socket connector of the Cisco cable to the modem cable, and not directly to the AS/400’s port.'''</blockquote>

It seems desirable to also provide means of Integration of serial only machinery into LANs. Cisco IOS provides functionality for such scenarios.

== Software Requirements ==
Basically:
* Some flavor of OS/400,
* Cisco IOS for your particular model with a certain feature set.

See the ''Cisco Feature Navigator'' weblink for additional information. Over a long time, Cisco has flooded the market with many different Cisco routers. They fall into broad generation groups, but there are still differences which model can (may) run which IOS feature set. Also, there is the definition of "officially supported" of "works", and the unofficial "works anyway in certain scenarios". Bottom line: The resulting combinations are way too many to be described here. A general rule of thumb: The bigger the image, and the more characters the classic feature set description has, the more likely it will have what you need.

It's important to understand the roles of the different involved components.
* the serial-only machine ''Fiona'' is an ''APPN end node'',
* the protocol to running over the serial cable is either SDLC, or X.25,
* the Cisco router converts the SDLC (SDLLC) or X.25 (QLLC) frames to a format being compatible with Token Ring,
* Fiona's APPN session terminates on ''Nibbler''.<ref>This can be another AS/400 but is not necessarily so.</ref>

== Configuration preparations ==
Obtain the resource names of the serial ports.

On the AS/400 systems, type <code>wrkhdwrsc *cmn</code> to get a list of communication hardware, and associated ports. Examples:

* V3/SPD:
'''Resource Type Text'''
CMB01 917B Combined function IOP
LIN01 2609 Comm Adapter
LIN011 2609 V.24 Port
LIN012 2609 V.24 Port

* V4/PCI:
'''Resource Type Status Text'''
LIN01 2720 Operational Comm Adapter
CMN01 2720 Operational V.24 Port

<blockquote>'''Note!''' OS/400 V3 seems to not designate ports as ''CMN'', but as ''LIN'' with three digits. Newer releases designate ports on an adapter as ''CMN''.</blockquote>

On Cisco IOS, type <code>show interfaces description</code> to get a list of interfaces. Serial interfaces are designated by starting with ''Se''.
Interface Status Protocol Description
Et0 up up
Se0 down down

Apart from this, components are expected to have some basic configuration settings applied:
* OS/400:
** Basic network settings reviewed in <code>dspneta</code> and subsequently <code>chgneta</code>
** <code>QAUTOCFG</code> system variable switched to ''on''
** LAN configuration established for LAN capable machines
* Cisco IOS:
** Basic settings applied
** Basic network configuration established

== Scenario 1: Purely local SNA APPN connection over SDLC ==
[[File:AS400-SDLC-Cisco-Ring-AS400.png|frame|center|Network Plan]]

This scenario is for when all involved components are reasonably close together physically, e. g. in the same room.

* Pro: Fairly easy to configure, applicable to other machinery than just AS/400's,
* Con: Maximum speed is 19200 bps.

=== Configuration: Cisco IOS (2612) ===
source-bridge ring-group 512
dlsw local-peer
!
interface Serial0/0
bandwidth 19
no ip address
encapsulation sdlc
load-interval 60
clock rate 19200
sdlc role prim-xid-poll
sdlc vmac 0004.acad.5900
sdlc address C0
sdlc partner 0004.acad.50d5 C0
sdlc line-speed 19200
sdlc simultaneous full-datmode
sdlc dlsw C0
hold-queue 128 out
no shutdown
!
interface TokenRing0/0
[…]
source-bridge 59 1 512

=== Configuration: OS/400 (Fiona) ===
crtctlappc ctld(nibbler) linktype(*sdlc) maxframe(1033) rmtcpname(nibbler) stnadr(c0) nodetype(*calc) tmsgrpnbr(*calc) autodltdev(*no) cmnrcylmt(10 1)

crtlinsdlc lind(sdlclin) rsrcname(lin011) nrzi(*no) linespeed(19200) maxframe(1033) duplex(*full) linkspeed(19200) ctl(nibbler) cmnrcylmt(10 1)

=== Notes ===
* The number in <code>source-bridge ring-group 512</code> is completely arbitrary.
* <code>sdlc vmac</code> is the virtual MAC address Fiona is assigned on the Token Ring. The last byte '''must''' be 00, while IOS sets the last byte to the SDLC station address being given later.
* <code>sdlc address</code> must be the same value as the <code>STNADR</code> parameter in the controller description.
* <code>sdlc partner</code> creates an association from Nibbler’s MAC address on the Token Ring to the SDLC address of Fiona.
* <code>clock rate</code> and <code>sdlc line-speed</code> must match each other, and the <code>LINESPEED</code> parameter of the line description.
* <code>sdlc simultaneous full-datmode</code> corresponds (most likely<ref>There are also ''half-duplex'' and ''full-duplex'' commands to configure an interface which aren't used here.</ref>) to the line description's ''DUPLEX(*FULL)''.
* The <code>source-bridge</code> statement in the physical Token Ring interface assigns the attached ring the number 59, designates it to the source bridge number 1, and bridges traffic to the virtual ring (group) number 512.
* Because auto configuration is enabled, the controller- and device descriptions for Fiona system will be created automatically at the first successful connection attempt to Nibbler.

Unclear:
* How is the serial interface’s traffic redirected to the ring group 512? The group number is referenced globally, and in the Token Ring interface, which hints to the fact that you can’t use this in a complex configuration with more than one ring group, probably?

Proven to work:
* Cisco 2612 with added WIC-1T, and image C2600-BINO3S3, Version 12.3(26)
* Cisco 1601-R, and image C1600-BNR2SY, Version 12.3(26)

=== Initiation, and function verification ===
* On Fiona, vary on line and controller descriptions:
vrycfg cfgobj(sdlclin) cfgtype(*lin) status(*on)
* After a brief pause, the Cisco console should indicate that the serial port goes up:<ref>If you’re connected remotely, make sure you’ve set <code>term moni</code>.</ref>
%LINK-3-UPDOWN: Interface Serial0/0, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to up
* On Fiona, looking into the QSYSOPR-Message Queue should show that the line has successfully been varied on, and a connection to the controller ''NIBBLER'' has been established through SDLCLIN.
* On the Cisco Router, you should see output of <code>show interface ser0/0</code> similar to the following:
Serial0/0 is up, line protocol is up
Hardware is PowerQUICC Serial
MTU 1500 bytes, BW 19 Kbit, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation SDLC, loopback not set
Router link station role: PRIMARY (DCE)
Router link station metrics:
slow-poll not configured
T1 (reply time out) 300 milliseconds
N1 (max frame size) 16472 bits
N2 (retry count) 7
poll-pause-timer 10 milliseconds
poll-limit-value 1
k (windowsize) 7
modulo 8
sdlc vmac: 0004.ACAD.59--
sdlc addr C0 state is CONNECT
cls_state is CLS_IN_SESSION
VS 5, VR 6, Remote VR 5, Current retransmit count 0
Hold queue: 0/200 IFRAMEs 1109/1325
TESTs 0/0 XIDs 2258/19, DMs 0/0 FRMRs 0/1
RNRs 1/0 SNRMs 10/0 DISC/RDs 3/1 REJs 0/0
Poll: clear, Poll count: 0, ready for poll, chain: C0/C0
Last input never, output 00:00:00, output hang never
Last clearing of "show interface" counters 1d17h
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/128 (size/max)
1 minute input rate 0 bits/sec, 49 packets/sec
1 minute output rate 0 bits/sec, 49 packets/sec
7467200 packets input, 15548792 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 21 giants, 0 throttles
21 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
7468810 packets output, 15116960 bytes, 0 underruns
0 output errors, 0 collisions, 26 interface resets
0 output buffer failures, 0 output buffers swapped out
10 carrier transitions
DCD=up DSR=up DTR=up RTS=up CTS=up
* On the Cisco Router, you should see output of <code>show dlsw local-circuit</code> similar to the following:
key mac-addr sap state port rif
2197187452 0004.acad.59c0 04 CONNECTED Se0/0 --no rif--
PCEP: 82AB8B88 UCEP: 82F66B7C
0004.acad.50d5 04 CONNECTED To0/0 0600.2001.03B0
PCEP: 82F511AC UCEP: 82F66B7C

* On Nibbler, you should see Fiona in <code>wrkappnsts option(*loc)</code><ref>Note that this command doesn't exist in V3.</ref>.

=== Configuration corrections ===
The APPC Controller on Nibbler has been automatically created with default values. This includes <code>maxframe</code> being set to the default for Token Ring, aka 16393 Bytes. This '''will''' result in connection instabilities, if not corrected.
* On Fiona vary off line and controller descriptions (optional):
vrycfg cfgobj(sdlclin) cfgtype(*lin) status(*off)
* On the Token Ring-AS/400 vary off the controller description:
vrycfg cfgobj(fiona) cfgtype(*ctl) status(*off)
* Change configuration to match parameters:
chgctlappc ctld(fiona) maxframe(1033) inlcnn(*ans) nodetype(*calc) autodltdev(*no) cmnrcylmt(10 1) ctlown(*user)
* I suggest to run <code>wrkctld</code> and manually set <code>swtdsc</code> (press F11) to ''*no''. Otherwise, you'll get a log of unneeded messages about torn down connections. It depends on the OS release if this option shows up.
* Vary on configuration objects on both AS/400, starting with Nibbler.
vrycfg cfgobj(fiona) cfgtype(*ctl) status(*on)
vrycfg cfgobj(sdlclin) cfgtype(*lin) status(*on)

You now should be able to enjoy a stable, albeit somewhat slow connection to your incarnation of Fiona, with each and every service running over SNA.

== Scenario 2: Remote SNA APPN connection over SDLC and DLSw ==
[[File:AS400-SDLC-Cisco-DLSw-Ring-AS400.png|frame|center|Network Plan]]

This scenario shows a configuration when connectivity between the two involved AS/400's is limited to TCP/IP, e. g. Ethernet or even WAN/VPN. An additional Router is required, here this is a Cisco 1601-R. This scenario uses DLSw transport for passing traffic between the involved routers. Otherwise, the configuration on Fiona and Nibbler is the same. Hence, this isn't repeated here.

* Pro: Still fairly easy to configure, applicable to other machinery than just AS/400's,
* Con: Maximum speed is still 19200 bps.

The main differences for the Cisco configuration is the establishment of ''Data Link Switching'' (DLSw), because of this, only configuration differences are pointed out.

=== Configuration: Cisco IOS (2612) ===
This one has the IP address 192.168.1.5.
no dlsw local-peer
source-bridge fst-peername 192.168.1.5
source-bridge keepalive 12
source-bridge ring-group 512
dlsw local-peer peer-id 192.168.1.5 lf 1500 keepalive 12 biu-segment
dlsw remote-peer 0 tcp 192.168.1.97

=== Configuration: Cisco IOS (1601-R) ===
This one has the IP address 192.168.1.97.
source-bridge fst-peername 192.168.1.97
source-bridge keepalive 12
source-bridge ring-group 512
dlsw local-peer peer-id 192.168.1.97 lf 1500 keepalive 12 biu-segment
dlsw remote-peer 0 tcp 192.168.1.5

=== Notes ===
The purely router-local ring-group 512 has now been connected through a TCP-Session over DLSw between both involved routers.

If both routers are located in the same L2 segment, one can use FST instead of TCP. I didn't get this to work, most likely because I'm using Ethernet Subinterfaces with Vlan-Tags on my 2612.

Proven to work:
* Cisco 2612 with added WIC-1T, and image C2600-BINO3S3, Version 12.3(26)
* Cisco 1601-R, and image C1600-BNR2SY, Version 12.3(26)

=== Initiation, and function verification ===
Initiation procedure is the same as noted above.

You should see output akin to the following for the <code>show dlsw peers</code> command.
Peers: state pkts_rx pkts_tx type drops ckts TCP uptime
TCP 192.168.1.5 CONNECT 131 131 conf 0 1 0 00:19:47
Total number of connected peers: 1
Total number of connections: 1

=== Configuration corrections ===
Corrections procedure is the same as noted above, if the controller description has been created automatically.

== Scenario 3: Remote SNA APPN connection over X.25 and DLSw ==
[[File:AS400-X25-Cisco-DLSw-Ring-AS400.png|frame|center|Network Plan]]

This scenario builds on the previously established DLSw scenario. The main difference is that instead of SDLC, X.25 is used as transport protocol on the serial link. All other configurations are the same.

* Pro: Maximum speed is 64 kbps, more than three times SDLC,
* Con: More complicated to configure, possibly not applicable to other machinery than just AS/400's

The main differences for the Cisco configuration is the establishment of ''X.25'', because of this, only configuration differences are pointed out.

=== Configuration: Cisco IOS (1601-R) ===
First, you need to reset the serial interface to its default values, to get rid of the SDLC configuration quickly.
default interface Serial0

Next, the new configuration is established.
interface Serial0
description Fiona LIN011
bandwidth 64
no ip address
encapsulation x25 dce
load-interval 60
x25 modulo 128
x25 ltc 100
x25 win 8
x25 wout 8
x25 ips 1024
x25 ops 1024
x25 pvc 1 qllc 0004.acad.59c0
ignore-dcd
clock rate 64000
qllc dlsw pvc 1 vmacaddr 0004.acad.59c0 partner 0004.acad.50d5

=== Configuration: OS/400 (Fiona) ===
crtlinx25 lind(x25line) rsrcname(lin011) lglchle((001 *pvc)) netadr(00000000000000) cnninit(*local) interface(*rs232v24) linespeed(19200) dftpktsize(1024) modulus(128) dftwdwsize(8) linkspeed(64000) cmnrcylmt(10 1)

crtctlappc ctld(nibbler) linktype(*x25) line(x25line) maxframe(1024) rmtcpname(nibbler) exchid(05641700) netlvl(1984) lglchlid(001) nodetype(*calc) tmsgrpnbr(*calc) autodltdev(*no) cmnrcylmt(10 1)

=== Notes ===
* The <code>x25 pvc</code>, and <code>qllc dlsw pvc 1</code> work together to establish a virtual MAC address for the X.25 virtual circuit, and the eventual Token Ring peer.
* You cannot create the line description with the full speed outright due to error CPD26DC (Maximum line speed for RS-232/V.24 is 19200 bps.). Create the line with <code>linespeed(19200)</code>, and subsequently edit the lind again, setting the desired speed of 64 kbps.
* The ''exchid'' of Nibbler can be found by viewing its line description for the Token Ring IOA.

Proven to work:
* Cisco 2612 with added WIC-1T, and image C2600-BINO3S3, Version 12.3(26)
* Cisco 1601-R, and image C1600-BNR2SY, Version 12.3(26)

=== Initiation, and function verification ===
Initiation procedure is the same as noted above.

You should see output akin to the following for the <code>show x25 interface serial0</code> command.
PVC 1, State: D1, Interface: Serial0
Started 00:20:54, last input 00:10:30, output 00:10:31
qllc 0004.acad.59c0
Window size input: 8, output: 8
Packet size input: 1024, output: 1024
PS: 80 PR: 80 ACK: 79 Remote PR: 80 RCNT: 1 RNR: no
P/D state timeouts: 0 timer (secs): 0
data bytes 21173/110662 packets 208/209 Resets 1/0 RNRs 0/0 REJs 0/0 INTs 0/0

You should see output akin to the following for the <code>show qllc serial0</code> command.
Interface Serial0
vc 1
Circuit State P4/D1, Logical Link State QLOpened 0004.acad.59c0(04)->0004.acad.50d5(04)
0 packets held

=== Configuration corrections ===
Corrections procedure is the same as noted for Scenario 1, if the controller description has been created automatically.

== Scenario 3a: IP over X.25 ==
This scenario builds on the previously established X.25 scenario. It adds TCP/IP transport over a secondary X.25 virtual circuit.

* 192.168.1.246 is the IP address for Fiona,
* 192.168.1.245 is the IP address for the Cisco 1601-R.

=== Configuration: Cisco IOS (1601-R) ===
Only parameters to be changed are mentioned.
interface Serial0
ip address 192.168.1.245 255.255.255.252
x25 pvc 2 ip 192.168.1.246

=== Configuration: OS/400 (Fiona) ===
First, you need to add another virtual circuit to the line description. You can't do that remotely, because you must vary off the line.
vrycfg cfgobj(x25lin011) cfgtype(*lin) status(*off)
chglinx25 lind(x25line) lglchle((001 *pvc) (002 *pvc))
vrycfg cfgobj(x25lin011) cfgtype(*lin) status(*on)

Then you can add the according TCP/IP interface configuration.
addtcpifc intnetadr('192.168.1.246') lind(x25line) subnetmask('255.255.255.252') mtu(1024) pvclglchli(002)
addtcprte rtedest(*dftroute) subnetmask(*none) nexthop('192.168.1.245') mtu(1024)
addtcprsi intnetadr('192.168.1.245') pvclglchli(002)

=== Notes ===
Proven to work:
* Cisco 1601-R, and image C1600-BNR2SY, Version 12.3(26)

=== Initiation, and function verification ===
Depending on if you have started TCP/IP before, you need to issue either <code>strtcp</code>, or <code>strtcpifc intnetadr('192.168.1.246')</code>.

You should see output akin to the following for the <code>show x25 interface serial0</code> command.
PVC 1, State: D1, Interface: Serial0
Started 03:07:34, last input 00:09:47, output 00:09:47
qllc 0004.acad.59c0
Window size input: 8, output: 8
Packet size input: 1024, output: 1024
PS: 122 PR: 36 ACK: 35 Remote PR: 122 RCNT: 1 RNR: no
P/D state timeouts: 0 timer (secs): 0
data bytes 2915564/2073274 packets 3733/2832 Resets 3/0 RNRs 0/0 REJs 0/0 INTs 0/0
PVC 2, State: D1, Interface: Serial0
Started 00:22:29, last input 00:18:33, output 00:18:33
Connects <no address> <-> ip 192.168.59.246
Data PID none
Window size input: 8, output: 8
Packet size input: 1024, output: 1024
PS: 29 PR: 24 ACK: 23 Remote PR: 29 RCNT: 1 RNR: no
P/D state timeouts: 0 timer (secs): 0
data bytes 1965/1917 packets 29/24 Resets 0/1 RNRs 0/0 REJs 0/0 INTs 0/0

=== Configuration corrections ===
How to establish routing within your local LAN for the example subnet being described above is not within the scope of this article.

Also, issue <code>go cfgtcp</code>, and check/correct configurations, such as DNS information, services to be started at IPL time, etc.

== See also ==
* [[Serial Cables IDs]]
* [[RS-232 Modem Cable Pinout]]
* [[Integrating LAN-less Machines into a local Token Ring]]
* [[Configuring X.25 link through Cisco IP network]]
* [[Configuring TCP/IP and SLIP with Cisco-Router and V3R2]]
* [[Start TCP/IP at IPL]]

== Weblinks ==
* [https://en.wikipedia.org/wiki/RS-232#Timing_signals RS-232 timing signals], Wikipedia
* [https://www.cisco.com/c/en/us/support/docs/routers/10000-series-routers/46800-cab232mtfc.html#cab-232fc Serial Cable CAB-232FC], Cisco.com
* [https://cfnng.cisco.com/archived-data Cisco Feature Navigator], Cisco.com
* [https://www.cisco.com/c/en/us/td/docs/ios/bridging/configuration/guide/15-s/br-15-s-book/br_dlsw_plus.html#wp1075136 DLSw+ translation between SDLC and Token Ring media example], Cisco.com
* [https://en.wikipedia.org/wiki/RS-232#Timing_signals RS-232 timing signals], Wikipedia
* [https://www.cisco.com/c/en/us/td/docs/ios/bridging/configuration/guide/15SY/br_15_sy_book.html Bridging and IBM Networking Configuration Guide], Cisco IOS Release 15SY
* [https://website.fis.agh.edu.pl/complab/doc/Cisco_IOS_11.0/cbook/cx25.htm Configuring X.25 and LAPB] on Cisco IOS, Faculty of Physics and Applied Computer Science Poland<ref>Very old documentation linked intentionally. Note: The configuration option ''tunnel'' was renamed to ''xot'' in newer IOS releases.</ref>
* [https://public.dhe.ibm.com/systems/power/docs/systemi/v6r1/en_US/sc415405.pdf X.25 Network Support] for OS/400, IBM.com

== Footnotes ==
<references />

== Acknowledgements ==
Thanks to Dave Brown for initial pointers.

[[Category: Hardware Configuration Guide‏]]
[[Category: Software Configuration Guide‏]]

ZuluSCSI

2026-08-25T11:40:00Z

PoC: /* Disk drive support */ Caveat added

'''ZuluSCSI''' by Rabbit Hole Computing is a comparatively new family of SCSI device emulators featuring an SD card based backing store. Distinct features to older, similar devices is support for Wide-SCSI, Ultra-Speed, and a fast CPU.

ZuluSCSI also features an OpenSource firmware, so it can be extended comparatively easily.

__TOC__

For most AS/400 machines, you actually want a ZuluSCSI wide, because it offers the best performance.

The ZuluSCSI firmware can emulate multiple devices at once. There is no real need to add multiple Zulus to a given SCSI bus. One Zulu can easily saturate even the UltraWide SCSI bus of a 9401-150, and due to the SD card, delays are minimal. You can gain more performance with bigger machines, if they have multiple SCSI buses, though.

== Hardware overview ==
Depending on the exact model, boards themselves have three DIP switches and tiny push buttons:
* 1: switch to initator mode,
* 2: enable debug log,
* 3: enable SCSI termination.

The push buttons call the functions:
* Bootloader, for firmware-recovery,
* Eject.

Also, three LEDs are provided, for indication of
* 2.8 V power OK,
* 3.3 V power OK,
* SD-card activity.

The device itself needs 5 V power, and can be powered by:
* the USB port,
* the termpower line of the SCSI bus,
* molex style power connectors.

Usually, the integrated USB port is configured as USB modem, for usage with a terminal emulator. You can use the Linux or macOS ''screen'' command for that. Depending on your operating system, you need to find out what device file is created when plugging the Zulu's USB port. On Linux, it's <tt>/dev/ttyACM''n''</tt> — ''n'' being a digit, usually 0. On macOS, it's <tt>/dev/tty.usbmodem*</tt>, with a row of digits appended on behalf of the <tt>*</tt>.

The firmware presents a simple menu driven UI for some tasks.

There is no need to shut down the device itself, it's safe to "pull the plug" when there is no activity. The Operating System running on the attached computer should, though.

== Configuration ==
Configuration itself is usually automatic, according to the files and directories found on the SD card. The SD card has either a FAT32<ref>Limiting files to max. 4 GiB in size</ref> or exFAT file system, the firmware understands both. It's easier to use the SD card with a card reader on a newer computer to create configurations, and files. The SD card is hotplug capable, and upon reinsertation, the ZuluSCSI reinitializes itself according to the SD card's content.

Three devices classes are of general interest in the AS/400 world:
* Disk (DASD),
* CD/DVD (Optical),
* Tape.

=== Files ===
File names are composed as follows:
<nowiki><TT><ID>[any text].<ext></nowiki>
^^ ^
| +-------------- SCSI ID character (byte offset 2)
+------------------- two-character type prefix (case-insensitive)

* '''TT''':
:{|class="wikitable"
!TT
!Device type
!Default block size
|-
|HD
|Hard disk (fixed)
|align="right"|512 Bytes
|-
|CD
|CD-ROM (optical)
|align="right"|2048 Bytes
|-
|TP
|Sequential (tape)
|align="right"|512 Bytes
|}
* The '''ID''' is exactly one char, and must be given in hexadecimal. This matters only for IDs ≥ 10.
* '''any text''' is entirely optional.
* The '''file extension''' doesn't matter.

=== Directories ===
For a device usually allowing dynamic addition and removal of media — CD-ROM-, and tape drives. The naming scheme follows the same structure as files, but ''[any text]'' must be omitted.

Files within the directories can be freely named, and are used in alphabetical order.<ref>Either through the ''Eject'' button, or the media menu.</ref>

=== Configuration file ===
In addition, a configuration file can be supplied to provide additional information to either all or one emulated device. Having a ''zuluscsi.ini'' is normally optional, but for enabling AS/400 quirks, it's mandatory.

The configuration file must be named ''zuluscsi.ini'', and is in a simple ini-style format. It has a global <tt>[SCSI]</tt> section to apply settings to all devices, and <tt>[SCSI''n'']</tt>, where ''n'' is the ID of the given SCSI devices.

== Examples ==
These are in the scope of AS/400.

=== Tape drive support ===
* create directory <code>TP0</code>,
* populate with one or more 0 byte files named <code>*.tap</code> files, e. g. by using the Unix <code>touch</code>,
* use the serial console to attach image(s) to the drive.
* ''zuluscsi.ini'':
[SCSI]
System="AS400_PPC"

[SCSI0]
TapeDensity = 0x25

Caveats:
* When you choose an image file through the USB port's media menu, make sure that you not only choose an image file, but afterwards ''insert'' it!
* If you replace a hardware tape drive, make sure to delete your old tape device file first, then IPL, check/set the new device name in DST, and have auto-configuration create the new device file during the following IPL.

This configuration has been tested over the course of multiple weeks:
* Occasional <tt>go save</tt> 21,
* daily differential backups,
* occasional single file restores.

Tested with Firmware 2026-06-12, 9401-150, V4R5.

=== CD drive support ===
* create directory <code>CD0</code>,
* populate with one or more readymade ISO images,
* use the serial console to attach image(s) to the drive.

No special handling for the ID in ''zuluscsi.ini''.

Caveats:
* When you choose an image file through the USB port's media menu, make sure that you not only choose an image file, but afterwards ''insert'' it!
* If you replace a hardware CD drive, make sure to delete your old CD device file first, then IPL, check/set the new device name in DST, and have auto-configuration create the new device file during the following IPL.

Tested with Firmware 2026-08-07, 9401-150, V4R4: IPL only so far.

=== Disk drive support ===
The officially released code base is able to present a singular #6717, 8.5 GiB disk drive to the system, initialize, and install SLIC + base OS/400 + LPPs + PTFs.

* Generate disk image:
dd if=/dev/zero of=HD6.img bs=522 count=17177940 status=progress
* ''zuluscsi.ini'':
[SCSI]
System = AS400_PPC

[SCSI6]
PrefetchBytes = 0

Caveats:
* Writes to the emulated disk are very slow compared to reads.
* One user with a RP2040 reported failure for the disk to be recognized. Prerelease firmware solved the issue.

Fully tested with Firmware 2026-08-21, 9401-150, V4R4.

== Current state ==
We have to differ three hardware generations when considering Zulu vs. AS/400:
{|class="wikitable"
! 
!CISC/IMPI, 520 bytes/block disks
!RISC/SPD, 520/522 bytes/block disks
!RISC/PCI, 522 bytes/block disks
|-
!CD-ROM
|Not supported
|Untested
|Works
|-
!Tape
|Fails, hangs with SRC early.
|Untested
|Works
|-
!Disk
|Fails, hangs with SRC early.
|Untested
|Works
|}

All successful tests so far have been based on a ZuluSCSI wide board, while the CISC tests have been done with a ZuluSCSI Blaster.

== Next ==
These features are completed, partially tested, but did not make it to the official releases yet:
* More disk profiles, loadable in ''zuluscsi.ini'' via external file ''as400_disk_definitions.txt'', so different types than the built-in 522 bytes, 8.5 GiB #6717 can be assigned.
** Shellscript to generate more ''as400_disk_definitions.txt'' entries from real disks connected to a SCSI controller when ran under Linux
** Because of serial numbers currently being hard coded, only one disk per type should be used
* Allowed more memory to accommodate the necessary VPD SCSI pages for multiple disks
* Present captured real tape VPD/SCSI data from IBM SLR5/QIC1000 when using <code>Device = "AS400_PPC"</code> or <code>Device = "AS400_CISC"</code> in an ID stanza
* Created a new build profile for the ZuluSCSI Blaster, removing all the add-on code being unneeded when used with AS/400

== See also ==
* [[Ordinary Harddisks on the AS/400]]
* [[Tape Drives on old AS/400]]
* [[SRC]], aka System Reference Code

== Weblinks ==
* [https://zuluscsi.com ZuluSCSI Website] — see the <tt>☰</tt> button top right for more details
* [https://github.com/ZuluSCSI/ZuluSCSI-firmware ZuluSCSI-firmware], GitHub

== Footnotes ==
<references />

[[Category:Hardware Configuration Guide]]

ZuluSCSI

2026-08-25T10:45:14Z

PoC: Next

'''ZuluSCSI''' by Rabbit Hole Computing is a comparatively new family of SCSI device emulators featuring an SD card based backing store. Distinct features to older, similar devices is support for Wide-SCSI, Ultra-Speed, and a fast CPU.

ZuluSCSI also features an OpenSource firmware, so it can be extended comparatively easily.

__TOC__

For most AS/400 machines, you actually want a ZuluSCSI wide, because it offers the best performance.

The ZuluSCSI firmware can emulate multiple devices at once. There is no real need to add multiple Zulus to a given SCSI bus. One Zulu can easily saturate even the UltraWide SCSI bus of a 9401-150, and due to the SD card, delays are minimal. You can gain more performance with bigger machines, if they have multiple SCSI buses, though.

== Hardware overview ==
Depending on the exact model, boards themselves have three DIP switches and tiny push buttons:
* 1: switch to initator mode,
* 2: enable debug log,
* 3: enable SCSI termination.

The push buttons call the functions:
* Bootloader, for firmware-recovery,
* Eject.

Also, three LEDs are provided, for indication of
* 2.8 V power OK,
* 3.3 V power OK,
* SD-card activity.

The device itself needs 5 V power, and can be powered by:
* the USB port,
* the termpower line of the SCSI bus,
* molex style power connectors.

Usually, the integrated USB port is configured as USB modem, for usage with a terminal emulator. You can use the Linux or macOS ''screen'' command for that. Depending on your operating system, you need to find out what device file is created when plugging the Zulu's USB port. On Linux, it's <tt>/dev/ttyACM''n''</tt> — ''n'' being a digit, usually 0. On macOS, it's <tt>/dev/tty.usbmodem*</tt>, with a row of digits appended on behalf of the <tt>*</tt>.

The firmware presents a simple menu driven UI for some tasks.

There is no need to shut down the device itself, it's safe to "pull the plug" when there is no activity. The Operating System running on the attached computer should, though.

== Configuration ==
Configuration itself is usually automatic, according to the files and directories found on the SD card. The SD card has either a FAT32<ref>Limiting files to max. 4 GiB in size</ref> or exFAT file system, the firmware understands both. It's easier to use the SD card with a card reader on a newer computer to create configurations, and files. The SD card is hotplug capable, and upon reinsertation, the ZuluSCSI reinitializes itself according to the SD card's content.

Three devices classes are of general interest in the AS/400 world:
* Disk (DASD),
* CD/DVD (Optical),
* Tape.

=== Files ===
File names are composed as follows:
<nowiki><TT><ID>[any text].<ext></nowiki>
^^ ^
| +-------------- SCSI ID character (byte offset 2)
+------------------- two-character type prefix (case-insensitive)

* '''TT''':
:{|class="wikitable"
!TT
!Device type
!Default block size
|-
|HD
|Hard disk (fixed)
|align="right"|512 Bytes
|-
|CD
|CD-ROM (optical)
|align="right"|2048 Bytes
|-
|TP
|Sequential (tape)
|align="right"|512 Bytes
|}
* The '''ID''' is exactly one char, and must be given in hexadecimal. This matters only for IDs ≥ 10.
* '''any text''' is entirely optional.
* The '''file extension''' doesn't matter.

=== Directories ===
For a device usually allowing dynamic addition and removal of media — CD-ROM-, and tape drives. The naming scheme follows the same structure as files, but ''[any text]'' must be omitted.

Files within the directories can be freely named, and are used in alphabetical order.<ref>Either through the ''Eject'' button, or the media menu.</ref>

=== Configuration file ===
In addition, a configuration file can be supplied to provide additional information to either all or one emulated device. Having a ''zuluscsi.ini'' is normally optional, but for enabling AS/400 quirks, it's mandatory.

The configuration file must be named ''zuluscsi.ini'', and is in a simple ini-style format. It has a global <tt>[SCSI]</tt> section to apply settings to all devices, and <tt>[SCSI''n'']</tt>, where ''n'' is the ID of the given SCSI devices.

== Examples ==
These are in the scope of AS/400.

=== Tape drive support ===
* create directory <code>TP0</code>,
* populate with one or more 0 byte files named <code>*.tap</code> files, e. g. by using the Unix <code>touch</code>,
* use the serial console to attach image(s) to the drive.
* ''zuluscsi.ini'':
[SCSI]
System="AS400_PPC"

[SCSI0]
TapeDensity = 0x25

Caveats:
* When you choose an image file through the USB port's media menu, make sure that you not only choose an image file, but afterwards ''insert'' it!
* If you replace a hardware tape drive, make sure to delete your old tape device file first, then IPL, check/set the new device name in DST, and have auto-configuration create the new device file during the following IPL.

This configuration has been tested over the course of multiple weeks:
* Occasional <tt>go save</tt> 21,
* daily differential backups,
* occasional single file restores.

Tested with Firmware 2026-06-12, 9401-150, V4R5.

=== CD drive support ===
* create directory <code>CD0</code>,
* populate with one or more readymade ISO images,
* use the serial console to attach image(s) to the drive.

No special handling for the ID in ''zuluscsi.ini''.

Caveats:
* When you choose an image file through the USB port's media menu, make sure that you not only choose an image file, but afterwards ''insert'' it!
* If you replace a hardware CD drive, make sure to delete your old CD device file first, then IPL, check/set the new device name in DST, and have auto-configuration create the new device file during the following IPL.

Tested with Firmware 2026-08-07, 9401-150, V4R4: IPL only so far.

=== Disk drive support ===
The officially released code base is able to present a singular #6717, 8.5 GiB disk drive to the system, initialize, and install SLIC + base OS/400 + LPPs + PTFs.

* Generate disk image:
dd if=/dev/zero of=HD6.img bs=522 count=17177940 status=progress
* ''zuluscsi.ini'':
[SCSI]
System = AS400_PPC

[SCSI6]
PrefetchBytes = 0

Caveats:
* Writes to the emulated disk are very slow compared to reads.

Fully tested with Firmware 2026-08-21, 9401-150, V4R4.

== Current state ==
We have to differ three hardware generations when considering Zulu vs. AS/400:
{|class="wikitable"
! 
!CISC/IMPI, 520 bytes/block disks
!RISC/SPD, 520/522 bytes/block disks
!RISC/PCI, 522 bytes/block disks
|-
!CD-ROM
|Not supported
|Untested
|Works
|-
!Tape
|Fails, hangs with SRC early.
|Untested
|Works
|-
!Disk
|Fails, hangs with SRC early.
|Untested
|Works
|}

All successful tests so far have been based on a ZuluSCSI wide board, while the CISC tests have been done with a ZuluSCSI Blaster.

== Next ==
These features are completed, partially tested, but did not make it to the official releases yet:
* More disk profiles, loadable in ''zuluscsi.ini'' via external file ''as400_disk_definitions.txt'', so different types than the built-in 522 bytes, 8.5 GiB #6717 can be assigned.
** Shellscript to generate more ''as400_disk_definitions.txt'' entries from real disks connected to a SCSI controller when ran under Linux
** Because of serial numbers currently being hard coded, only one disk per type should be used
* Allowed more memory to accommodate the necessary VPD SCSI pages for multiple disks
* Present captured real tape VPD/SCSI data from IBM SLR5/QIC1000 when using <code>Device = "AS400_PPC"</code> or <code>Device = "AS400_CISC"</code> in an ID stanza
* Created a new build profile for the ZuluSCSI Blaster, removing all the add-on code being unneeded when used with AS/400

== See also ==
* [[Ordinary Harddisks on the AS/400]]
* [[Tape Drives on old AS/400]]
* [[SRC]], aka System Reference Code

== Weblinks ==
* [https://zuluscsi.com ZuluSCSI Website] — see the <tt>☰</tt> button top right for more details
* [https://github.com/ZuluSCSI/ZuluSCSI-firmware ZuluSCSI-firmware], GitHub

== Footnotes ==
<references />

[[Category:Hardware Configuration Guide]]

ZuluSCSI

2026-08-25T10:21:23Z

PoC: /* Examples */ Disk support

'''ZuluSCSI''' by Rabbit Hole Computing is a comparatively new family of SCSI device emulators featuring an SD card based backing store. Distinct features to older, similar devices is support for Wide-SCSI, Ultra-Speed, and a fast CPU.

ZuluSCSI also features an OpenSource firmware, so it can be extended comparatively easily.

__TOC__

For most AS/400 machines, you actually want a ZuluSCSI wide, because it offers the best performance.

The ZuluSCSI firmware can emulate multiple devices at once. There is no real need to add multiple Zulus to a given SCSI bus. One Zulu can easily saturate even the UltraWide SCSI bus of a 9401-150, and due to the SD card, delays are minimal. You can gain more performance with bigger machines, if they have multiple SCSI buses, though.

== Hardware overview ==
Depending on the exact model, boards themselves have three DIP switches and tiny push buttons:
* 1: switch to initator mode,
* 2: enable debug log,
* 3: enable SCSI termination.

The push buttons call the functions:
* Bootloader, for firmware-recovery,
* Eject.

Also, three LEDs are provided, for indication of
* 2.8 V power OK,
* 3.3 V power OK,
* SD-card activity.

The device itself needs 5 V power, and can be powered by:
* the USB port,
* the termpower line of the SCSI bus,
* molex style power connectors.

Usually, the integrated USB port is configured as USB modem, for usage with a terminal emulator. You can use the Linux or macOS ''screen'' command for that. Depending on your operating system, you need to find out what device file is created when plugging the Zulu's USB port. On Linux, it's <tt>/dev/ttyACM''n''</tt> — ''n'' being a digit, usually 0. On macOS, it's <tt>/dev/tty.usbmodem*</tt>, with a row of digits appended on behalf of the <tt>*</tt>.

The firmware presents a simple menu driven UI for some tasks.

There is no need to shut down the device itself, it's safe to "pull the plug" when there is no activity. The Operating System running on the attached computer should, though.

== Configuration ==
Configuration itself is usually automatic, according to the files and directories found on the SD card. The SD card has either a FAT32<ref>Limiting files to max. 4 GiB in size</ref> or exFAT file system, the firmware understands both. It's easier to use the SD card with a card reader on a newer computer to create configurations, and files. The SD card is hotplug capable, and upon reinsertation, the ZuluSCSI reinitializes itself according to the SD card's content.

Three devices classes are of general interest in the AS/400 world:
* Disk (DASD),
* CD/DVD (Optical),
* Tape.

=== Files ===
File names are composed as follows:
<nowiki><TT><ID>[any text].<ext></nowiki>
^^ ^
| +-------------- SCSI ID character (byte offset 2)
+------------------- two-character type prefix (case-insensitive)

* '''TT''':
:{|class="wikitable"
!TT
!Device type
!Default block size
|-
|HD
|Hard disk (fixed)
|align="right"|512 Bytes
|-
|CD
|CD-ROM (optical)
|align="right"|2048 Bytes
|-
|TP
|Sequential (tape)
|align="right"|512 Bytes
|}
* The '''ID''' is exactly one char, and must be given in hexadecimal. This matters only for IDs ≥ 10.
* '''any text''' is entirely optional.
* The '''file extension''' doesn't matter.

=== Directories ===
For a device usually allowing dynamic addition and removal of media — CD-ROM-, and tape drives. The naming scheme follows the same structure as files, but ''[any text]'' must be omitted.

Files within the directories can be freely named, and are used in alphabetical order.<ref>Either through the ''Eject'' button, or the media menu.</ref>

=== Configuration file ===
In addition, a configuration file can be supplied to provide additional information to either all or one emulated device. Having a ''zuluscsi.ini'' is normally optional, but for enabling AS/400 quirks, it's mandatory.

The configuration file must be named ''zuluscsi.ini'', and is in a simple ini-style format. It has a global <tt>[SCSI]</tt> section to apply settings to all devices, and <tt>[SCSI''n'']</tt>, where ''n'' is the ID of the given SCSI devices.

== Examples ==
These are in the scope of AS/400.

=== Tape drive support ===
* create directory <code>TP0</code>,
* populate with one or more 0 byte files named <code>*.tap</code> files, e. g. by using the Unix <code>touch</code>,
* use the serial console to attach image(s) to the drive.
* ''zuluscsi.ini'':
[SCSI]
System="AS400_PPC"

[SCSI0]
TapeDensity = 0x25

Caveats:
* When you choose an image file through the USB port's media menu, make sure that you not only choose an image file, but afterwards ''insert'' it!
* If you replace a hardware tape drive, make sure to delete your old tape device file first, then IPL, check/set the new device name in DST, and have auto-configuration create the new device file during the following IPL.

This configuration has been tested over the course of multiple weeks:
* Occasional <tt>go save</tt> 21,
* daily differential backups,
* occasional single file restores.

Tested with Firmware 2026-06-12, 9401-150, V4R5.

=== CD drive support ===
* create directory <code>CD0</code>,
* populate with one or more readymade ISO images,
* use the serial console to attach image(s) to the drive.

No special handling for the ID in ''zuluscsi.ini''.

Caveats:
* When you choose an image file through the USB port's media menu, make sure that you not only choose an image file, but afterwards ''insert'' it!
* If you replace a hardware CD drive, make sure to delete your old CD device file first, then IPL, check/set the new device name in DST, and have auto-configuration create the new device file during the following IPL.

Tested with Firmware 2026-08-07, 9401-150, V4R4: IPL only so far.

=== Disk drive support ===
The officially released code base is able to present a singular #6717, 8.5 GiB disk drive to the system, initialize, and install SLIC + base OS/400 + LPPs + PTFs.

* Generate disk image:
dd if=/dev/zero of=HD6.img bs=522 count=17177940 status=progress
* ''zuluscsi.ini'':
[SCSI]
System = AS400_PPC

[SCSI6]
PrefetchBytes = 0

Caveats:
* Writes to the emulated disk are very slow compared to reads.

Fully tested with Firmware 2026-08-21, 9401-150, V4R4.

== Current state ==
We have to differ three hardware generations when considering Zulu vs. AS/400:
{|class="wikitable"
! 
!CISC/IMPI, 520 bytes/block disks
!RISC/SPD, 520/522 bytes/block disks
!RISC/PCI, 522 bytes/block disks
|-
!CD-ROM
|Not supported
|Untested
|Works
|-
!Tape
|Fails, hangs with SRC early.
|Untested
|Works
|-
!Disk
|Fails, hangs with SRC early.
|Untested
|Works
|}

All successful tests so far have been based on a ZuluSCSI wide board, while the CISC tests have been done with a ZuluSCSI Blaster.

== See also ==
* [[Ordinary Harddisks on the AS/400]]
* [[Tape Drives on old AS/400]]
* [[SRC]], aka System Reference Code

== Weblinks ==
* [https://zuluscsi.com ZuluSCSI Website] — see the <tt>☰</tt> button top right for more details
* [https://github.com/ZuluSCSI/ZuluSCSI-firmware ZuluSCSI-firmware], GitHub

== Footnotes ==
<references />

[[Category:Hardware Configuration Guide]]

ZuluSCSI

2026-08-25T10:08:52Z

PoC: /* Current state */ Reworked

'''ZuluSCSI''' by Rabbit Hole Computing is a comparatively new family of SCSI device emulators featuring an SD card based backing store. Distinct features to older, similar devices is support for Wide-SCSI, Ultra-Speed, and a fast CPU.

ZuluSCSI also features an OpenSource firmware, so it can be extended comparatively easily.

__TOC__

For most AS/400 machines, you actually want a ZuluSCSI wide, because it offers the best performance.

The ZuluSCSI firmware can emulate multiple devices at once. There is no real need to add multiple Zulus to a given SCSI bus. One Zulu can easily saturate even the UltraWide SCSI bus of a 9401-150, and due to the SD card, delays are minimal. You can gain more performance with bigger machines, if they have multiple SCSI buses, though.

== Hardware overview ==
Depending on the exact model, boards themselves have three DIP switches and tiny push buttons:
* 1: switch to initator mode,
* 2: enable debug log,
* 3: enable SCSI termination.

The push buttons call the functions:
* Bootloader, for firmware-recovery,
* Eject.

Also, three LEDs are provided, for indication of
* 2.8 V power OK,
* 3.3 V power OK,
* SD-card activity.

The device itself needs 5 V power, and can be powered by:
* the USB port,
* the termpower line of the SCSI bus,
* molex style power connectors.

Usually, the integrated USB port is configured as USB modem, for usage with a terminal emulator. You can use the Linux or macOS ''screen'' command for that. Depending on your operating system, you need to find out what device file is created when plugging the Zulu's USB port. On Linux, it's <tt>/dev/ttyACM''n''</tt> — ''n'' being a digit, usually 0. On macOS, it's <tt>/dev/tty.usbmodem*</tt>, with a row of digits appended on behalf of the <tt>*</tt>.

The firmware presents a simple menu driven UI for some tasks.

There is no need to shut down the device itself, it's safe to "pull the plug" when there is no activity. The Operating System running on the attached computer should, though.

== Configuration ==
Configuration itself is usually automatic, according to the files and directories found on the SD card. The SD card has either a FAT32<ref>Limiting files to max. 4 GiB in size</ref> or exFAT file system, the firmware understands both. It's easier to use the SD card with a card reader on a newer computer to create configurations, and files. The SD card is hotplug capable, and upon reinsertation, the ZuluSCSI reinitializes itself according to the SD card's content.

Three devices classes are of general interest in the AS/400 world:
* Disk (DASD),
* CD/DVD (Optical),
* Tape.

=== Files ===
File names are composed as follows:
<nowiki><TT><ID>[any text].<ext></nowiki>
^^ ^
| +-------------- SCSI ID character (byte offset 2)
+------------------- two-character type prefix (case-insensitive)

* '''TT''':
:{|class="wikitable"
!TT
!Device type
!Default block size
|-
|HD
|Hard disk (fixed)
|align="right"|512 Bytes
|-
|CD
|CD-ROM (optical)
|align="right"|2048 Bytes
|-
|TP
|Sequential (tape)
|align="right"|512 Bytes
|}
* The '''ID''' is exactly one char, and must be given in hexadecimal. This matters only for IDs ≥ 10.
* '''any text''' is entirely optional.
* The '''file extension''' doesn't matter.

=== Directories ===
For a device usually allowing dynamic addition and removal of media — CD-ROM-, and tape drives. The naming scheme follows the same structure as files, but ''[any text]'' must be omitted.

Files within the directories can be freely named, and are used in alphabetical order.<ref>Either through the ''Eject'' button, or the media menu.</ref>

=== Configuration file ===
In addition, a configuration file can be supplied to provide additional information to either all or one emulated device. Having a ''zuluscsi.ini'' is normally optional, but for enabling AS/400 quirks, it's mandatory.

The configuration file must be named ''zuluscsi.ini'', and is in a simple ini-style format. It has a global <tt>[SCSI]</tt> section to apply settings to all devices, and <tt>[SCSI''n'']</tt>, where ''n'' is the ID of the given SCSI devices.

== Examples ==
These are in the scope of AS/400.

=== Tape drive support ===
* create directory <code>TP0</code>,
* populate with one or more 0 byte files named <code>*.tap</code> files, e. g. by using the Unix <code>touch</code>,
* use the serial console to attach image(s) to the drive.
* ''zuluscsi.ini'':
[SCSI]
System="AS400_PPC"

[SCSI0]
TapeDensity = 0x25

Caveats:
* When you choose an image file through the USB port's media menu, make sure that you not only choose an image file, but afterwards ''insert'' it!
* If you replace a hardware tape drive, make sure to delete your old tape device file first, then IPL, check/set the new device name in DST, and have auto-configuration create the new device file during the following IPL.

This configuration has been tested over the course of multiple weeks:
* Occasional <tt>go save</tt> 21,
* daily differential backups,
* occasional single file restores.

Tested with Firmware 2026-06-12, 9401-150, V4R5.

=== CD drive support ===
* create directory <code>CD0</code>,
* populate with one or more readymade ISO images,
* use the serial console to attach image(s) to the drive.

No special handling for the ID in ''zuluscsi.ini''.

Caveats:
* When you choose an image file through the USB port's media menu, make sure that you not only choose an image file, but afterwards ''insert'' it!
* If you replace a hardware CD drive, make sure to delete your old CD device file first, then IPL, check/set the new device name in DST, and have auto-configuration create the new device file during the following IPL.

Tested with Firmware 2026-08-07, 9401-150, V4R4: IPL only so far.

== Current state ==
We have to differ three hardware generations when considering Zulu vs. AS/400:
{|class="wikitable"
! 
!CISC/IMPI, 520 bytes/block disks
!RISC/SPD, 520/522 bytes/block disks
!RISC/PCI, 522 bytes/block disks
|-
!CD-ROM
|Not supported
|Untested
|Works
|-
!Tape
|Fails, hangs with SRC early.
|Untested
|Works
|-
!Disk
|Fails, hangs with SRC early.
|Untested
|Works
|}

All successful tests so far have been based on a ZuluSCSI wide board, while the CISC tests have been done with a ZuluSCSI Blaster.

== See also ==
* [[Ordinary Harddisks on the AS/400]]
* [[Tape Drives on old AS/400]]
* [[SRC]], aka System Reference Code

== Weblinks ==
* [https://zuluscsi.com ZuluSCSI Website] — see the <tt>☰</tt> button top right for more details
* [https://github.com/ZuluSCSI/ZuluSCSI-firmware ZuluSCSI-firmware], GitHub

== Footnotes ==
<references />

[[Category:Hardware Configuration Guide]]

Post-Install Optimizations

2026-08-22T16:02:13Z

PoC: PTF handling

OS/400 provides a lot of default values for variables (affecting the run-time environment) and program options. Some of these make sense, some of them are kept consistent with earlier versions of the OS because of compatibility reasons by IBM.

Some of these recommendations might not be appropriate for you by various reasons. Don't apply blindly. Know what you do, use the online help to retrieve background information on the topic in question.

The findings below are based on V4R5 with annotated exceptions for newer releases.

== Housekeeping ==
These are settings and scheduled jobs to keep your system uncluttered.

=== Change unneeded programs to not run ===
We most likely don't need to run ''lpd'' and ''smtpd'' to run per default.
CHGLPDA AUTOSTART(*NO)
CHGSMTPA AUTOSTART(*NO)

You can easily check all settings at once by using <code>UPDDTA QUSRSYS/QATOCSTART</code>. These are not needed in general.
* *DIRSRV
* *NETSVR
* *SLP

Depending on OS version, not all entries may be available.

=== Change uninstalled programs to not run ===
If you did not install the Ultimedia package, you can remove the pre started job from the QSYSWRK subsystem description to make it not generate an error message at IPL time.
RMVPJE SBSD(QSYSWRK) PGM(QUMEDIA/QUMBPJTC)

If you did not install the Directory Services package (aka LDAP), you can remove the auto started jobs from the QSYSWRK subsystem description to make them not generate an error message at IPL time.
RMVAJE SBSD(QSYSWRK) JOB(QGLDPUBA)
RMVAJE SBSD(QSYSWRK) JOB(QGLDPUBE)

Both is valid and tested for V4R5. Note that newer releases moved the background jobs to the base OS so there is no error message when starting them. I have not tested if they're required to run, though.

If you did not install the performance tools, you don't need trying to start the performance data collector:
RMVAJE SBSD(QCTL) JOB(QPFRCOL)

I can't remember if the latter is valid for V4R5. It's valid for V3R2, though.

=== Cleanup unneeded stuff ===
These objects come by default at OS install time, are not needed to my knowledge, and thus can be safely deleted:
DLTOUTQ OUTQ(QDKT)
DLTOUTQ OUTQ(QPFROUTQ)
DLTOUTQ OUTQ(QPRINTS)
DLTF FILE(QPRINTS)
DLTOUTQ OUTQ(QPRINT2)
DLTF FILE(QPRINT2)
DLTOUTQ OUTQ(QTPPPOUTQ)
DLTDEVD DEVD(QESPAP)
DLTDEVD DEVD(QIADSP)
DLTDEVD DEVD(QIAPRT)
DLTDEVD DEVD(QQAHOST)
DLTDEVD DEVD(QTIDA)
DLTDEVD DEVD(QTIDA2)
DLTCTLD CTLD(QESCTL)
DLTCTLD CTLD(QTICTL)
DLTLIND LIND(QESLINE)
DLTLIND LIND(QTILINE)

== System Values ==
System values are like environment variables as known from common operating systems. They influence system operation. I recommend the following changes.

=== System Control ===
* Change work environment to separate subsystems for different kind of jobs. This also makes it easy to introduce your own subsystems.
CHGSYSVAL SYSVAL(QCTLSBSD) VALUE('QCTL QSYS')
* Set automatic DST adjustment, and UTC offset. This value is valid for Central Europe (Berlin, Paris, …) '''Note!''' This variable is not available in V4R5. See [[#Weblinks|Weblinks]] below.
CHGSYSVAL SYSVAL(QTIMZON) VALUE('QP0100CET2')
* Adjust time to automatically end disconnected interactive jobs (sessions) to one day.
CHGSYSVAL SYSVAL(QDSCJOBITV) VALUE('1440')

=== (Memory) Allocation ===
* Adjust automatic performance values only at runtime, not at IPL.<ref>If you change the amount of memory for the machine, temporarily adjust the value to '2', make the memory change and then change the value back to '3' — no further IPL needed.</ref> This allows the system to automatically adjust memory allocations and activity levels to minimize paging (disk I/O).
CHGSYSVAL SYSVAL(QPFRADJ) VALUE('3')
* Allow memory pools to self adjust the paging block size depending on jobs running. This is called ''Expert Cache''. You can adjust the maximum active jobs per pool in the <code>WRKSHRPOOL</code> display.<ref>Press <code>F21</code> to switch to view 2 or 3 to have adjustment possibilities.</ref>
CHGSHRPOOL POOL(*BASE) PAGING(*CALC)
CHGSHRPOOL POOL(*INTERACT) PAGING(*CALC)
CHGSHRPOOL POOL(*SPOOL) PAGING(*CALC)
* Reservations for job related data structures at IPL time. See <code>DSPSYSSTS</code> and set to slightly more than the ''Jobs in System'' value to be seen there when the system is working "normal".<ref>Press <code>F21</code> to switch to view 2 or 3 to see the overall job count.</ref>
CHGSYSVAL SYSVAL(QTOTJOB) VALUE(100)
* Reservations for job related data structures at IPL time. See <code>WRKACTJOB</code> and set to slightly more than the ''Active Jobs'' value to be seen there when the system is working "normal".
CHGSYSVAL SYSVAL(QACTJOB) VALUE(95)
* Maximize TCP buffers for maximum performance, especially on faster links.
CHGTCPA TCPRCVBUF(8388608) TCPSNDBUF(8388608)
* Make sure, database tasks can use system resources as needed.
CHGSYSVAL SYSVAL(QQRYDEGREE) VALUE(*OPTIMIZE)
* When interactive jobs require more CPU time than being allowed by default (2 seconds),<ref>This is set in *CLS objects.</ref> to finish a block of processing, allow that memory to be taken from the *BASE pool. Advantage: The QINTER subsystem pool will not be subject to auto adjustment because of jobs which are supposed to run in batch.
CHGSYSVAL SYSVAL(QTSEPOOL) VALUE(*BASE)

=== Message-and-Logging ===
* Allow immediate deletion of problem reports.
CHGSYSVAL SYSVAL(QPRBHLDITV) VALUE(0)
* Do not log software errors. We can't do much about these anyway, seen from a hobbyist viewpoint.
CHGSYSVAL SYSVAL(QSFWERRLOG) VALUE(*NOLOG)
* Maximize Central Syslog (viewable with <code>DSPLOG</code> size to lessen rotation frequency. Depending on OS version only ''VALUE(32767)'' may be valid.
CHGSYSVAL SYSVAL(QHSTLOGSIZ) VALUE(*DAILY)
* Raise allowed unsuccessful sign on tries before taking action.
CHGSYSVAL SYSVAL(QMAXSIGN) VALUE('15')
* Minimize logging for sessions disconnected beause of device errors.
CHGSYSVAL SYSVAL(QDEVRCYACN) VALUE(*ENDJOBNOLIST)

=== Security System Values ===
* Unrestrict automatic creation of system objects triggered by external (network) requests.
CHGSYSVAL SYSVAL(QAUTOVRT) VALUE(*NOMAX)
* Allow restore with all security relevant flags.
CHGSYSVAL SYSVAL(QALWOBJRST) VALUE(*ALL)
* For TCP connections to work, we need encrypted passwords.
CHGDDMTCPA PWDRQD(*ENCRYPTED)
* Allow ''QSYSOPR'' signon to all devices.
CHGSYSVAL SYSVAL(QLMTSECOFR) VALUE('0')
* Raise maximum password length to maximum value.<ref>In newer OS versions, an additional variable ''QPWDLVL'' allows even longer passwords.</ref>
CHGSYSVAL SYSVAL(QPWDMAXLEN) VALUE(10)
* Raise minimum passsword length for security reasons.
CHGSYSVAL SYSVAL(QPWDMINLEN) VALUE(8)

=== Misc ===
* PTF install shall be done on unattended IPL time, and don't try to report problems to IBM directly.<ref>Needs prior setup for ''Electronic Customer Support''.</ref>
CHGSRVA PTFINSTYP(*DLYALL) RPTPRBAUTO(*NO)
* Provide European style formatting.
CHGSYSVAL SYSVAL(QCURSYM) VALUE('€')
CHGSYSVAL SYSVAL(QDECFMT) VALUE('J')
CHGSYSVAL SYSVAL(QSRTSEQ) VALUE(*LANGIDUNQ)<ref>This value isn't available with V4R5. You can use ''*LANGIDSHR'' there.</ref>
CHGSYSVAL SYSVAL(QDATFMT) VALUE('DMY')<ref>Default value for 2924 (US English) is MDY.</ref>
* Allow background compiling in PDM as ordinary user, and submitting batch jobs in general.
GRTOBJAUT OBJ(QGPL/QBATCH) OBJTYPE(*JOBD) USER(*PUBLIC) AUT(*USE)
* Tweaking automatic cleanup (like ''logrotate'').
CHGCLNUP ALWCLNUP(*YES) STRTIME('02:22:22') USRMSG(7) SYSMSG(3) SYSPRT(7) SYSLOG(14) CALITM(*KEEP)
* Change general SNA networking attributes. This is one '''long''' line. Take care to get it completely.
CHGNETA JOBACN(*SEARCH) VRTAUTODEV(254) MDMCNTRYID(DE)

=== Charset Conversion ===
In addition, OS/400 has a default value of 65535 for <code>QCCSID</code>. It should be set to a value being dependent on the installed language, to enable automatic translation of data on disk to the display device, and back. For Germany, the correct value is 273, and for US, it's 37. A good hint is to check your 5250 emulator program for possible values.

== IPL Customization ==
With this procedure, the current startup program for the OS can be retrieved for easy customization.
RTVCLSRC PGM(QSTRUP) SRCFILE(QCLSRC)
WRKMBRPDM FILE(QCLSRC) MBR(QSTRUP) MBRTYPE(CLP)
CRTCLPGM PGM(QGPL/QSTRUP)

To activate your changes, run <code>WRKSYSVAL SYSVAL(QSTRUPPGM)</code> and change the values to reflect the new program object in QGPL. '''Note''': On a used system's install, the previous owner might have already done a customized QSTRUP. See <code>DSPSYSVAL QSTRUPPGM</code> which one is the currently set startup program before accidentally overwriting!

Notable use cases for changing <code>QSTRUP</code> would be to make SNA Distribution Services, and TCP/IP (on older releases than V4R5) start at IPL time.

New entries must be located after the ''IF COND'' statement and ''DONE:'' label. Always put a ''MONMSG MSGID(CPF0000)'' after each statement. Failing to do so will not ignore any errors but make the IPL script terminate abnormally in case of an error and possibly leave you with an inaccessible system.

Examples:
* Start TCP/IP:
QSYS/STRTCP
MONMSG MSGID(CPF0000)
<blockquote>'''Note:''' TCP/IP on V4R5 and later is by IBM provided default automatically started with an appropriate autostart entry <code>struptcpip</code> in the <code>qsyswrk</code> subsystem description. No action is necessary in the startup CL!</blockquote>

* Start SNADS:
QSYS/STRSBS SBSD(QSNADS)
MONMSG MSGID(CPF0000)

== Change Program Defaults ==
This establishes different default behavior of some programs which makes life somewhat easier.<ref>Some people highly oppose against changing default values because the default values have been provided for a reason. But then, the <code>CHGCMDDFT</code> also has been provided for a reason.</ref> At least noting down the changed programs and their former values is recommended, for example in <code>QGPL/QTXTSRC.CMDDFT</code>.
<blockquote>'''Note:''' CL applications might run a command with the changed default values, in turn combining (new) defaults and submitted parameters into an invalid combination of parameters which might lead to run-time errors. As far as I'm aware, my proposed changes are compatible with such situations.</blockquote>

* File creation and change defaults:
** Enforce immediate return to program error handling instead of make programs seem to hang (<code>wait…</code>),
** Enforce reusing deleted record space,<ref>If there is no access path defined, sequentially read records are no longer guaranteed to *be in timely order (FIFO)!</ref>
** Remove sizing restrictions,<ref>A runaway process filling the disks to 100 % is not stopped prior!</ref>
** Use a smaller access path size for probably increased performance,
** Allow automatic LF rebuild when running <code>chgpf</code>.
CHGCMDDFT CMD(CRTPF) NEWDFT('SIZE(*NOMAX *N *N) WAITFILE(*IMMED) WAITRCD(*IMMED) REUSEDLT(*YES)')
CHGCMDDFT CMD(CRTSRCPF) NEWDFT('SIZE(*NOMAX *N *N) ACCPTHSIZ(*MAX4GB)')
CHGCMDDFT CMD(CHGPF) NEWDFT('DLTDEPLF(*YES) SIZE(*NOMAX *N *N) WAITFILE(*IMMED) WAITRCD(*IMMED) REUSEDLT(*YES)')
CHGCMDDFT CMD(CRTLF) NEWDFT('WAITFILE(*IMMED) WAITRCD(*IMMED) ACCPTHSIZ(*MAX4GB)')
CHGCMDDFT CMD(CHGLF) NEWDFT('WAITFILE(*IMMED) WAITRCD(*IMMED) ACCPTHSIZ(*MAX4GB)')
* Menus usually go into the library with the application's other objects. Change current library to there, so applications can find their objects.<ref>It might be beneficial to individually use <code>CURLIB(*NOCHG)</code> for higher level menu objects being put into libraries which are part of the default library search list (''*LIBL'') — such as ''QGPL'' — to not needlessly change the default library in a for some users unexpected way.</ref>
CHGCMDDFT CMD(CRTMNU) NEWDFT('CURLIB(*MNULIB)')
* No unnecessary wait for power down. <code>CONFIRM(*NO)</code> can be added for newer releases to suppress prompting.
CHGCMDDFT CMD(PWRDWNSYS) NEWDFT('OPTION(*IMMED) ENDSBSOPT(*NOJOBLOG)')
* Don't waste time displaying a not so very much interesting screen prior to connection.
CHGCMDDFT CMD(STRPASTHR) NEWDFT('PASTHRSCN(*NO)')

Be aware that reinstalls, or applying PTFs can overwrite command objects and thus their changed default values. Also note, hat installing a secondary language on a system also installs a separate set of <code>*cmd</code> objects for that language. You may want to apply the defaults with qualified object names to these, too.

== Regular Cleanup jobs ==
See job comment TEXT for details. These are '''long''' lines. Take care to get it completely.
ADDJOBSCDE JOB(PRGPRB) CMD(DLTPRB STATUS(*CLOSED)) FRQ(*WEEKLY) SCDDATE(*NONE) SCDDAY(*ALL) SCDTIME('13:22:00') MSGQ(*LIBL/QSYSOPR) TEXT('Purge closed and deletable problem entries')
ADDJOBSCDE JOB(RCLTMPSTG) CMD(RCLTMPSTG DAYS(30)) FRQ(*MONTHLY) SCDDATE(*MONTHSTR) SCDDAY(*NONE) SCDTIME('13:24:00') MSGQ(*LIBL/QSYSOPR) TEXT('Reclaim temporary storage')
ADDJOBSCDE JOB(RTVDSKINF) CMD(RTVDSKINF) FRQ(*MONTHLY) SCDDATE(*MONTHSTR) SCDDAY(*NONE) SCDTIME('13:34:00') MSGQ(*LIBL/QSYSOPR) TEXT('Retrieve disk space stats')
ADDJOBSCDE JOB(QPGMRCLR) CMD(CLRMSGQ MSGQ(QPGMR) CLEAR(*KEEPUNANS)) FRQ(*WEEKLY) SCDDATE(*NONE) SCDDAY(*ALL) SCDTIME('07:07:07') RCYACN(*NOSBM) MSGQ(*NONE) TEXT('Delete uninteresting messages')

== PTF handling ==
To save space on disk and backup media, you may want to consider applying all PTFs permanently. You cannot remove them afterwards, but that largely doesn't really matter for older and hobbyist systems.

From a console, first run an `ENDSYS (*IMMED)` to get the system into restricted, state. Then run
APYPTF LICPGM(*ALL) SELECT(*ALL) APY(*PERM) DELAYED(*YES) IPLAPY(*YES)

This will apply all PTFs permanently upon next normal IPL. Note you should IPL from the A-side to allow changes to the B side being made.

A final IPL to the B side gets you the fully PTF'd system.

== Re-Enable InfoSeeker ==
Only necessary for newer V4R4 and newer. If the command isn't known, don't bother: Then your release is so new that it's gone entirely.

See also: [[Reviving InfoSeeker]]

CRTDTAARA DTAARA(QUSRSYS/QBMGINFSKR) TYPE(*CHAR) LEN(8)<ref>Works in V4R5. The <code>STRINFSKR</code> command is not included anymore in IBM i 7.1, and probably earlier releases.</ref>

== Additional Steps tested with V7R2 ==
After trying to enter SST, one gets the message that the password has expired. But the password cannot be changed. Re-IPL '''in manual mode''', do not IPL but enter DST, and change password as directed.

* Choose ''5. Work with DST environment'' and ''3. Service tools user IDs''.
** Disable the "backdoor" profile ''11111111'',
** ''Change password'' for ''QSECOFR'', ''Set password to expired'' to ''2=No''.
* Press F12 and choose ''6. Service tools security data''.
** Enter 0 into the field ''8. Password expiration interval in days'', 8 into the ''Selection'' field, and press return.
** Enter a high number (like 12) into the field ''9. Maximum sign-on attempts allowed'', 9 into the ''Selection'' field, and press return.
** Enter 0 into the field ''10. Duplicate password control'', 10 into the ''Selection'' field, and press return.

Now exit DST.

You may choose to enter SST, enter 7 for ''Work with system security'', and set ''Allow a service tools user ID with a default and expired password to change its own password'' to ''1=Yes''. Since we changed password expiry to ''never'', this step is entirely optional.

== See also ==
* [[Change Command Defaults for File-Commands]]
* [[How to properly shut down your AS/400]]

== Weblinks ==
* [https://archive.midrange.com/midrange-l/199912/msg01738.html STRINFSKR], Midrange Mailing-List
* [https://github.com/PoC-dev/as400-autodst as400-autodst], GitHub

== Footnotes ==
<references />

[[Category: System Administration]]

Post-Install Optimizations

2026-08-22T14:29:41Z

PoC: /* Housekeeping */ Short cut

OS/400 provides a lot of default values for variables (affecting the run-time environment) and program options. Some of these make sense, some of them are kept consistent with earlier versions of the OS because of compatibility reasons by IBM.

Some of these recommendations might not be appropriate for you by various reasons. Don't apply blindly. Know what you do, use the online help to retrieve background information on the topic in question.

The findings below are based on V4R5 with annotated exceptions for newer releases.

== Housekeeping ==
These are settings and scheduled jobs to keep your system uncluttered.

=== Change unneeded programs to not run ===
We most likely don't need to run ''lpd'' and ''smtpd'' to run per default.
CHGLPDA AUTOSTART(*NO)
CHGSMTPA AUTOSTART(*NO)

You can easily check all settings at once by using <code>UPDDTA QUSRSYS/QATOCSTART</code>. These are not needed in general.
* *DIRSRV
* *NETSVR
* *SLP

Depending on OS version, not all entries may be available.

=== Change uninstalled programs to not run ===
If you did not install the Ultimedia package, you can remove the pre started job from the QSYSWRK subsystem description to make it not generate an error message at IPL time.
RMVPJE SBSD(QSYSWRK) PGM(QUMEDIA/QUMBPJTC)

If you did not install the Directory Services package (aka LDAP), you can remove the auto started jobs from the QSYSWRK subsystem description to make them not generate an error message at IPL time.
RMVAJE SBSD(QSYSWRK) JOB(QGLDPUBA)
RMVAJE SBSD(QSYSWRK) JOB(QGLDPUBE)

Both is valid and tested for V4R5. Note that newer releases moved the background jobs to the base OS so there is no error message when starting them. I have not tested if they're required to run, though.

If you did not install the performance tools, you don't need trying to start the performance data collector:
RMVAJE SBSD(QCTL) JOB(QPFRCOL)

I can't remember if the latter is valid for V4R5. It's valid for V3R2, though.

=== Cleanup unneeded stuff ===
These objects come by default at OS install time, are not needed to my knowledge, and thus can be safely deleted:
DLTOUTQ OUTQ(QDKT)
DLTOUTQ OUTQ(QPFROUTQ)
DLTOUTQ OUTQ(QPRINTS)
DLTF FILE(QPRINTS)
DLTOUTQ OUTQ(QPRINT2)
DLTF FILE(QPRINT2)
DLTOUTQ OUTQ(QTPPPOUTQ)
DLTDEVD DEVD(QESPAP)
DLTDEVD DEVD(QIADSP)
DLTDEVD DEVD(QIAPRT)
DLTDEVD DEVD(QQAHOST)
DLTDEVD DEVD(QTIDA)
DLTDEVD DEVD(QTIDA2)
DLTCTLD CTLD(QESCTL)
DLTCTLD CTLD(QTICTL)
DLTLIND LIND(QESLINE)
DLTLIND LIND(QTILINE)

== System Values ==
System values are like environment variables as known from common operating systems. They influence system operation. I recommend the following changes.

=== System Control ===
* Change work environment to separate subsystems for different kind of jobs. This also makes it easy to introduce your own subsystems.
CHGSYSVAL SYSVAL(QCTLSBSD) VALUE('QCTL QSYS')
* Set automatic DST adjustment, and UTC offset. This value is valid for Central Europe (Berlin, Paris, …) '''Note!''' This variable is not available in V4R5. See [[#Weblinks|Weblinks]] below.
CHGSYSVAL SYSVAL(QTIMZON) VALUE('QP0100CET2')
* Adjust time to automatically end disconnected interactive jobs (sessions) to one day.
CHGSYSVAL SYSVAL(QDSCJOBITV) VALUE('1440')

=== (Memory) Allocation ===
* Adjust automatic performance values only at runtime, not at IPL.<ref>If you change the amount of memory for the machine, temporarily adjust the value to '2', make the memory change and then change the value back to '3' — no further IPL needed.</ref> This allows the system to automatically adjust memory allocations and activity levels to minimize paging (disk I/O).
CHGSYSVAL SYSVAL(QPFRADJ) VALUE('3')
* Allow memory pools to self adjust the paging block size depending on jobs running. This is called ''Expert Cache''. You can adjust the maximum active jobs per pool in the <code>WRKSHRPOOL</code> display.<ref>Press <code>F21</code> to switch to view 2 or 3 to have adjustment possibilities.</ref>
CHGSHRPOOL POOL(*BASE) PAGING(*CALC)
CHGSHRPOOL POOL(*INTERACT) PAGING(*CALC)
CHGSHRPOOL POOL(*SPOOL) PAGING(*CALC)
* Reservations for job related data structures at IPL time. See <code>DSPSYSSTS</code> and set to slightly more than the ''Jobs in System'' value to be seen there when the system is working "normal".<ref>Press <code>F21</code> to switch to view 2 or 3 to see the overall job count.</ref>
CHGSYSVAL SYSVAL(QTOTJOB) VALUE(100)
* Reservations for job related data structures at IPL time. See <code>WRKACTJOB</code> and set to slightly more than the ''Active Jobs'' value to be seen there when the system is working "normal".
CHGSYSVAL SYSVAL(QACTJOB) VALUE(95)
* Maximize TCP buffers for maximum performance, especially on faster links.
CHGTCPA TCPRCVBUF(8388608) TCPSNDBUF(8388608)
* Make sure, database tasks can use system resources as needed.
CHGSYSVAL SYSVAL(QQRYDEGREE) VALUE(*OPTIMIZE)
* When interactive jobs require more CPU time than being allowed by default (2 seconds),<ref>This is set in *CLS objects.</ref> to finish a block of processing, allow that memory to be taken from the *BASE pool. Advantage: The QINTER subsystem pool will not be subject to auto adjustment because of jobs which are supposed to run in batch.
CHGSYSVAL SYSVAL(QTSEPOOL) VALUE(*BASE)

=== Message-and-Logging ===
* Allow immediate deletion of problem reports.
CHGSYSVAL SYSVAL(QPRBHLDITV) VALUE(0)
* Do not log software errors. We can't do much about these anyway, seen from a hobbyist viewpoint.
CHGSYSVAL SYSVAL(QSFWERRLOG) VALUE(*NOLOG)
* Maximize Central Syslog (viewable with <code>DSPLOG</code> size to lessen rotation frequency. Depending on OS version only ''VALUE(32767)'' may be valid.
CHGSYSVAL SYSVAL(QHSTLOGSIZ) VALUE(*DAILY)
* Raise allowed unsuccessful sign on tries before taking action.
CHGSYSVAL SYSVAL(QMAXSIGN) VALUE('15')
* Minimize logging for sessions disconnected beause of device errors.
CHGSYSVAL SYSVAL(QDEVRCYACN) VALUE(*ENDJOBNOLIST)

=== Security System Values ===
* Unrestrict automatic creation of system objects triggered by external (network) requests.
CHGSYSVAL SYSVAL(QAUTOVRT) VALUE(*NOMAX)
* Allow restore with all security relevant flags.
CHGSYSVAL SYSVAL(QALWOBJRST) VALUE(*ALL)
* For TCP connections to work, we need encrypted passwords.
CHGDDMTCPA PWDRQD(*ENCRYPTED)
* Allow ''QSYSOPR'' signon to all devices.
CHGSYSVAL SYSVAL(QLMTSECOFR) VALUE('0')
* Raise maximum password length to maximum value.<ref>In newer OS versions, an additional variable ''QPWDLVL'' allows even longer passwords.</ref>
CHGSYSVAL SYSVAL(QPWDMAXLEN) VALUE(10)
* Raise minimum passsword length for security reasons.
CHGSYSVAL SYSVAL(QPWDMINLEN) VALUE(8)

=== Misc ===
* PTF install shall be done on unattended IPL time, and don't try to report problems to IBM directly.<ref>Needs prior setup for ''Electronic Customer Support''.</ref>
CHGSRVA PTFINSTYP(*DLYALL) RPTPRBAUTO(*NO)
* Provide European style formatting.
CHGSYSVAL SYSVAL(QCURSYM) VALUE('€')
CHGSYSVAL SYSVAL(QDECFMT) VALUE('J')
CHGSYSVAL SYSVAL(QSRTSEQ) VALUE(*LANGIDUNQ)<ref>This value isn't available with V4R5. You can use ''*LANGIDSHR'' there.</ref>
CHGSYSVAL SYSVAL(QDATFMT) VALUE('DMY')<ref>Default value for 2924 (US English) is MDY.</ref>
* Allow background compiling in PDM as ordinary user, and submitting batch jobs in general.
GRTOBJAUT OBJ(QGPL/QBATCH) OBJTYPE(*JOBD) USER(*PUBLIC) AUT(*USE)
* Tweaking automatic cleanup (like ''logrotate'').
CHGCLNUP ALWCLNUP(*YES) STRTIME('02:22:22') USRMSG(7) SYSMSG(3) SYSPRT(7) SYSLOG(14) CALITM(*KEEP)
* Change general SNA networking attributes. This is one '''long''' line. Take care to get it completely.
CHGNETA JOBACN(*SEARCH) VRTAUTODEV(254) MDMCNTRYID(DE)

=== Charset Conversion ===
In addition, OS/400 has a default value of 65535 for <code>QCCSID</code>. It should be set to a value being dependent on the installed language, to enable automatic translation of data on disk to the display device, and back. For Germany, the correct value is 273, and for US, it's 37. A good hint is to check your 5250 emulator program for possible values.

== IPL Customization ==
With this procedure, the current startup program for the OS can be retrieved for easy customization.
RTVCLSRC PGM(QSTRUP) SRCFILE(QCLSRC)
WRKMBRPDM FILE(QCLSRC) MBR(QSTRUP) MBRTYPE(CLP)
CRTCLPGM PGM(QGPL/QSTRUP)

To activate your changes, run <code>WRKSYSVAL SYSVAL(QSTRUPPGM)</code> and change the values to reflect the new program object in QGPL. '''Note''': On a used system's install, the previous owner might have already done a customized QSTRUP. See <code>DSPSYSVAL QSTRUPPGM</code> which one is the currently set startup program before accidentally overwriting!

Notable use cases for changing <code>QSTRUP</code> would be to make SNA Distribution Services, and TCP/IP (on older releases than V4R5) start at IPL time.

New entries must be located after the ''IF COND'' statement and ''DONE:'' label. Always put a ''MONMSG MSGID(CPF0000)'' after each statement. Failing to do so will not ignore any errors but make the IPL script terminate abnormally in case of an error and possibly leave you with an inaccessible system.

Examples:
* Start TCP/IP:
QSYS/STRTCP
MONMSG MSGID(CPF0000)
<blockquote>'''Note:''' TCP/IP on V4R5 and later is by IBM provided default automatically started with an appropriate autostart entry <code>struptcpip</code> in the <code>qsyswrk</code> subsystem description. No action is necessary in the startup CL!</blockquote>

* Start SNADS:
QSYS/STRSBS SBSD(QSNADS)
MONMSG MSGID(CPF0000)

== Change Program Defaults ==
This establishes different default behavior of some programs which makes life somewhat easier.<ref>Some people highly oppose against changing default values because the default values have been provided for a reason. But then, the <code>CHGCMDDFT</code> also has been provided for a reason.</ref> At least noting down the changed programs and their former values is recommended, for example in <code>QGPL/QTXTSRC.CMDDFT</code>.
<blockquote>'''Note:''' CL applications might run a command with the changed default values, in turn combining (new) defaults and submitted parameters into an invalid combination of parameters which might lead to run-time errors. As far as I'm aware, my proposed changes are compatible with such situations.</blockquote>

* File creation and change defaults:
** Enforce immediate return to program error handling instead of make programs seem to hang (<code>wait…</code>),
** Enforce reusing deleted record space,<ref>If there is no access path defined, sequentially read records are no longer guaranteed to *be in timely order (FIFO)!</ref>
** Remove sizing restrictions,<ref>A runaway process filling the disks to 100 % is not stopped prior!</ref>
** Use a smaller access path size for probably increased performance,
** Allow automatic LF rebuild when running <code>chgpf</code>.
CHGCMDDFT CMD(CRTPF) NEWDFT('SIZE(*NOMAX *N *N) WAITFILE(*IMMED) WAITRCD(*IMMED) REUSEDLT(*YES)')
CHGCMDDFT CMD(CRTSRCPF) NEWDFT('SIZE(*NOMAX *N *N) ACCPTHSIZ(*MAX4GB)')
CHGCMDDFT CMD(CHGPF) NEWDFT('DLTDEPLF(*YES) SIZE(*NOMAX *N *N) WAITFILE(*IMMED) WAITRCD(*IMMED) REUSEDLT(*YES)')
CHGCMDDFT CMD(CRTLF) NEWDFT('WAITFILE(*IMMED) WAITRCD(*IMMED) ACCPTHSIZ(*MAX4GB)')
CHGCMDDFT CMD(CHGLF) NEWDFT('WAITFILE(*IMMED) WAITRCD(*IMMED) ACCPTHSIZ(*MAX4GB)')
* Menus usually go into the library with the application's other objects. Change current library to there, so applications can find their objects.<ref>It might be beneficial to individually use <code>CURLIB(*NOCHG)</code> for higher level menu objects being put into libraries which are part of the default library search list (''*LIBL'') — such as ''QGPL'' — to not needlessly change the default library in a for some users unexpected way.</ref>
CHGCMDDFT CMD(CRTMNU) NEWDFT('CURLIB(*MNULIB)')
* No unnecessary wait for power down. <code>CONFIRM(*NO)</code> can be added for newer releases to suppress prompting.
CHGCMDDFT CMD(PWRDWNSYS) NEWDFT('OPTION(*IMMED) ENDSBSOPT(*NOJOBLOG)')
* Don't waste time displaying a not so very much interesting screen prior to connection.
CHGCMDDFT CMD(STRPASTHR) NEWDFT('PASTHRSCN(*NO)')

Be aware that reinstalls, or applying PTFs can overwrite command objects and thus their changed default values. Also note, hat installing a secondary language on a system also installs a separate set of <code>*cmd</code> objects for that language. You may want to apply the defaults with qualified object names to these, too.

== Regular Cleanup jobs ==
See job comment TEXT for details. These are '''long''' lines. Take care to get it completely.
ADDJOBSCDE JOB(PRGPRB) CMD(DLTPRB STATUS(*CLOSED)) FRQ(*WEEKLY) SCDDATE(*NONE) SCDDAY(*ALL) SCDTIME('13:22:00') MSGQ(*LIBL/QSYSOPR) TEXT('Purge closed and deletable problem entries')
ADDJOBSCDE JOB(RCLTMPSTG) CMD(RCLTMPSTG DAYS(30)) FRQ(*MONTHLY) SCDDATE(*MONTHSTR) SCDDAY(*NONE) SCDTIME('13:24:00') MSGQ(*LIBL/QSYSOPR) TEXT('Reclaim temporary storage')
ADDJOBSCDE JOB(RTVDSKINF) CMD(RTVDSKINF) FRQ(*MONTHLY) SCDDATE(*MONTHSTR) SCDDAY(*NONE) SCDTIME('13:34:00') MSGQ(*LIBL/QSYSOPR) TEXT('Retrieve disk space stats')
ADDJOBSCDE JOB(QPGMRCLR) CMD(CLRMSGQ MSGQ(QPGMR) CLEAR(*KEEPUNANS)) FRQ(*WEEKLY) SCDDATE(*NONE) SCDDAY(*ALL) SCDTIME('07:07:07') RCYACN(*NOSBM) MSGQ(*NONE) TEXT('Delete uninteresting messages')

== Re-Enable InfoSeeker ==
Only necessary for newer V4R4 and newer. If the command isn't known, don't bother: Then your release is so new that it's gone entirely.

See also: [[Reviving InfoSeeker]]

CRTDTAARA DTAARA(QUSRSYS/QBMGINFSKR) TYPE(*CHAR) LEN(8)<ref>Works in V4R5. The <code>STRINFSKR</code> command is not included anymore in IBM i 7.1, and probably earlier releases.</ref>

== Additional Steps tested with V7R2 ==
After trying to enter SST, one gets the message that the password has expired. But the password cannot be changed. Re-IPL '''in manual mode''', do not IPL but enter DST, and change password as directed.

* Choose ''5. Work with DST environment'' and ''3. Service tools user IDs''.
** Disable the "backdoor" profile ''11111111'',
** ''Change password'' for ''QSECOFR'', ''Set password to expired'' to ''2=No''.
* Press F12 and choose ''6. Service tools security data''.
** Enter 0 into the field ''8. Password expiration interval in days'', 8 into the ''Selection'' field, and press return.
** Enter a high number (like 12) into the field ''9. Maximum sign-on attempts allowed'', 9 into the ''Selection'' field, and press return.
** Enter 0 into the field ''10. Duplicate password control'', 10 into the ''Selection'' field, and press return.

Now exit DST.

You may choose to enter SST, enter 7 for ''Work with system security'', and set ''Allow a service tools user ID with a default and expired password to change its own password'' to ''1=Yes''. Since we changed password expiry to ''never'', this step is entirely optional.

== See also ==
* [[Change Command Defaults for File-Commands]]
* [[How to properly shut down your AS/400]]

== Weblinks ==
* [https://archive.midrange.com/midrange-l/199912/msg01738.html STRINFSKR], Midrange Mailing-List
* [https://github.com/PoC-dev/as400-autodst as400-autodst], GitHub

== Footnotes ==
<references />

[[Category: System Administration]]

System Internals:SLIC DASD device recognition

2026-08-21T14:09:55Z

PoC: Removed erroneous information

ZuluSCSI

2026-08-17T19:00:23Z

PoC: +CD

'''ZuluSCSI''' by Rabbit Hole Computing is a comparatively new family of SCSI device emulators featuring an SD card based backing store. Distinct features to older, similar devices is support for Wide-SCSI, Ultra-Speed, and a fast CPU.

ZuluSCSI also features an OpenSource firmware, so it can be extended comparatively easily.

__TOC__

For most AS/400 machines, you actually want a ZuluSCSI wide, because it offers the best performance.

The ZuluSCSI firmware can emulate multiple devices at once. There is no real need to add multiple Zulus to a given SCSI bus. One Zulu can easily saturate even the UltraWide SCSI bus of a 9401-150, and due to the SD card, delays are minimal. You can gain more performance with bigger machines, if they have multiple SCSI buses, though.

== Hardware overview ==
Depending on the exact model, boards themselves have three DIP switches and tiny push buttons:
* 1: switch to initator mode,
* 2: enable debug log,
* 3: enable SCSI termination.

The push buttons call the functions:
* Bootloader, for firmware-recovery,
* Eject.

Also, three LEDs are provided, for indication of
* 2.8 V power OK,
* 3.3 V power OK,
* SD-card activity.

The device itself needs 5 V power, and can be powered by:
* the USB port,
* the termpower line of the SCSI bus,
* molex style power connectors.

Usually, the integrated USB port is configured as USB modem, for usage with a terminal emulator. You can use the Linux or macOS ''screen'' command for that. Depending on your operating system, you need to find out what device file is created when plugging the Zulu's USB port. On Linux, it's <tt>/dev/ttyACM''n''</tt> — ''n'' being a digit, usually 0. On macOS, it's <tt>/dev/tty.usbmodem*</tt>, with a row of digits appended on behalf of the <tt>*</tt>.

The firmware presents a simple menu driven UI for some tasks.

There is no need to shut down the device itself, it's safe to "pull the plug" when there is no activity. The Operating System running on the attached computer should, though.

== Configuration ==
Configuration itself is usually automatic, according to the files and directories found on the SD card. The SD card has either a FAT32<ref>Limiting files to max. 4 GiB in size</ref> or exFAT file system, the firmware understands both. It's easier to use the SD card with a card reader on a newer computer to create configurations, and files. The SD card is hotplug capable, and upon reinsertation, the ZuluSCSI reinitializes itself according to the SD card's content.

Three devices classes are of general interest in the AS/400 world:
* Disk (DASD),
* CD/DVD (Optical),
* Tape.

=== Files ===
File names are composed as follows:
<nowiki><TT><ID>[any text].<ext></nowiki>
^^ ^
| +-------------- SCSI ID character (byte offset 2)
+------------------- two-character type prefix (case-insensitive)

* '''TT''':
:{|class="wikitable"
!TT
!Device type
!Default block size
|-
|HD
|Hard disk (fixed)
|align="right"|512 Bytes
|-
|CD
|CD-ROM (optical)
|align="right"|2048 Bytes
|-
|TP
|Sequential (tape)
|align="right"|512 Bytes
|}
* The '''ID''' is exactly one char, and must be given in hexadecimal. This matters only for IDs ≥ 10.
* '''any text''' is entirely optional.
* The '''file extension''' doesn't matter.

=== Directories ===
For a device usually allowing dynamic addition and removal of media — CD-ROM-, and tape drives. The naming scheme follows the same structure as files, but ''[any text]'' must be omitted.

Files within the directories can be freely named, and are used in alphabetical order.<ref>Either through the ''Eject'' button, or the media menu.</ref>

=== Configuration file ===
In addition, a configuration file can be supplied to provide additional information to either all or one emulated device. Having a ''zuluscsi.ini'' is normally optional, but for enabling AS/400 quirks, it's mandatory.

The configuration file must be named ''zuluscsi.ini'', and is in a simple ini-style format. It has a global <tt>[SCSI]</tt> section to apply settings to all devices, and <tt>[SCSI''n'']</tt>, where ''n'' is the ID of the given SCSI devices.

== Examples ==
These are in the scope of AS/400.

=== Tape drive support ===
* create directory <code>TP0</code>,
* populate with one or more 0 byte files named <code>*.tap</code> files, e. g. by using the Unix <code>touch</code>,
* use the serial console to attach image(s) to the drive.
* ''zuluscsi.ini'':
[SCSI]
System="AS400_PPC"

[SCSI0]
TapeDensity = 0x25

Caveats:
* When you choose an image file through the USB port's media menu, make sure that you not only choose an image file, but afterwards ''insert'' it!
* If you replace a hardware tape drive, make sure to delete your old tape device file first, then IPL, check/set the new device name in DST, and have auto-configuration create the new device file during the following IPL.

This configuration has been tested over the course of multiple weeks:
* Occasional <tt>go save</tt> 21,
* daily differential backups,
* occasional single file restores.

Tested with Firmware 2026-06-12, 9401-150, V4R5.

=== CD drive support ===
* create directory <code>CD0</code>,
* populate with one or more readymade ISO images,
* use the serial console to attach image(s) to the drive.

No special handling for the ID in ''zuluscsi.ini''.

Caveats:
* When you choose an image file through the USB port's media menu, make sure that you not only choose an image file, but afterwards ''insert'' it!
* If you replace a hardware CD drive, make sure to delete your old CD device file first, then IPL, check/set the new device name in DST, and have auto-configuration create the new device file during the following IPL.

Tested with Firmware 2026-08-07, 9401-150, V4R4: IPL only so far.

== Current state ==
In the scope of AS/400's, ZuluSCSI's disk support is still incomplete, while CD- and tape emulation are seemingly solid. Some progress has been made, but there are still some rough edges, normally leading to crash of the Operating System with a given ''System Reference Code''.

At the moment, the firmware supports only a single AS/400 specific DASD device type for PPC-AS (522 Bytes per sector).

=== Reports ===
* 2026-08-16, mikerm, 9406-170, Zulu firmware 2026-08-07. Trying to install V4R4 on the Zulu emulated DASD. Disk was created with <code>dd if=/dev/zero of=HD6.img bs=522 count=17177940 status=progress</code><ref>Per directions of one of the firmware developers.</ref>
** First try, ''prefetch'' setting at default (8k): halts at <code>B1934505</code> after IPL takes place from DASD
** Second try, ''prefetch'' set to 0: <code>B6080801</code> after IPL takes place from DASD. More progress, and much quicker LIC install, though.
** Configuration file used:
[SCSI]
LogModeData = 1
System = AS400_BS522

== See also ==
* [[Ordinary Harddisks on the AS/400]]
* [[Tape Drives on old AS/400]]
* [[SRC]], aka System Reference Code

== Weblinks ==
* [https://zuluscsi.com ZuluSCSI Website] — see the <tt>☰</tt> button top right for more details
* [https://github.com/ZuluSCSI/ZuluSCSI-firmware ZuluSCSI-firmware], GitHub

== Footnotes ==
<references />

[[Category:Hardware Configuration Guide]]

ZuluSCSI

2026-08-16T21:28:06Z

PoC: /* Hardware overview */ finished sentence

'''ZuluSCSI''' by Rabbit Hole Computing is a comparatively new family of SCSI device emulators featuring an SD card based backing store. Distinct features to older, similar devices is support for Wide-SCSI, Ultra-Speed, and a fast CPU.

ZuluSCSI also features an OpenSource firmware, so it can be extended comparatively easily.

__TOC__

For most AS/400 machines, you actually want a ZuluSCSI wide, because it offers the best performance.

The ZuluSCSI firmware can emulate multiple devices at once. There is no real need to add multiple Zulus to a given SCSI bus. One Zulu can easily saturate even the UltraWide SCSI bus of a 9401-150, and due to the SD card, delays are minimal. You can gain more performance with bigger machines, if they have multiple SCSI buses, though.

== Hardware overview ==
Depending on the exact model, boards themselves have three DIP switches and tiny push buttons:
* 1: switch to initator mode,
* 2: enable debug log,
* 3: enable SCSI termination.

The push buttons call the functions:
* Bootloader, for firmware-recovery,
* Eject.

Also, three LEDs are provided, for indication of
* 2.8 V power OK,
* 3.3 V power OK,
* SD-card activity.

The device itself needs 5 V power, and can be powered by:
* the USB port,
* the termpower line of the SCSI bus,
* molex style power connectors.

Usually, the integrated USB port is configured as USB modem, for usage with a terminal emulator. You can use the Linux or macOS ''screen'' command for that. Depending on your operating system, you need to find out what device file is created when plugging the Zulu's USB port. On Linux, it's <tt>/dev/ttyACM''n''</tt> — ''n'' being a digit, usually 0. On macOS, it's <tt>/dev/tty.usbmodem*</tt>, with a row of digits appended on behalf of the <tt>*</tt>.

The firmware presents a simple menu driven UI for some tasks.

There is no need to shut down the device itself, it's safe to "pull the plug" when there is no activity. The Operating System running on the attached computer should, though.

== Configuration ==
Configuration itself is usually automatic, according to the files and directories found on the SD card. The SD card has either a FAT32<ref>Limiting files to max. 4 GiB in size</ref> or exFAT file system, the firmware understands both. It's easier to use the SD card with a card reader on a newer computer to create configurations, and files. The SD card is hotplug capable, and upon reinsertation, the ZuluSCSI reinitializes itself according to the SD card's content.

Three devices classes are of general interest in the AS/400 world:
* Disk (DASD),
* CD/DVD (Optical),
* Tape.

=== Files ===
File names are composed as follows:
<nowiki><TT><ID>[any text].<ext></nowiki>
^^ ^
| +-------------- SCSI ID character (byte offset 2)
+------------------- two-character type prefix (case-insensitive)

* '''TT''':
:{|class="wikitable"
!TT
!Device type
!Default block size
|-
|HD
|Hard disk (fixed)
|align="right"|512 Bytes
|-
|CD
|CD-ROM (optical)
|align="right"|2048 Bytes
|-
|TP
|Sequential (tape)
|align="right"|512 Bytes
|}
* The '''ID''' is exactly one char, and must be given in hexadecimal. This matters only for IDs ≥ 10.
* '''any text''' is entirely optional.
* The '''file extension''' doesn't matter.

=== Directories ===
For a device usually allowing dynamic addition and removal of media — CD-ROM-, and tape drives. The naming scheme follows the same structure as files, but ''[any text]'' must be omitted.

Files within the directories can be freely named, and are used in alphabetical order.<ref>Either through the ''Eject'' button, or the media menu.</ref>

=== Configuration file ===
In addition, a configuration file can be supplied to provide additional information to either all or one emulated device. Having a ''zuluscsi.ini'' is normally optional, but for enabling AS/400 quirks, it's mandatory.

The configuration file must be named ''zuluscsi.ini'', and is in a simple ini-style format. It has a global <tt>[SCSI]</tt> section to apply settings to all devices, and <tt>[SCSI''n'']</tt>, where ''n'' is the ID of the given SCSI devices.

== Examples ==
These are in the scope of AS/400.

=== Tape drive support ===
* create directory <code>TP0</code>,
* populate with one or more 0 byte files named <code>*.tap</code> files, e. g. by using the Unix <code>touch</code>,
* use the serial console to attach image(s) to the drive.
* ''zuluscsi.ini'':
[SCSI]
System="AS400_PPC"

[SCSI0]
TapeDensity = 0x25

Caveats:
* When you choose an image file through the USB port's media menu, make sure that you not only choose an image file, but afterwards ''insert'' it!
* If you replace a hardware tape drive, make sure to delete your old tape device file first, then IPL, check/set the new device name in DST, and have auto-configuration create the new device file during the following IPL.

This configuration has been tested on a 9401-150 running V4R5 over the course of multiple weeks:
* Occasional <tt>go save</tt> 21,
* daily differential backups,
* occasional single file restores.

== Current state ==
In the scope of AS/400's, ZuluSCSI's disk support is still incomplete, while CD- and tape emulation are seemingly solid. Some progress has been made, but there are still some rough edges, normally leading to crash of the Operating System with a given ''System Reference Code''.

At the moment, the firmware supports only a single AS/400 specific DASD device type for PPC-AS (522 Bytes per sector).

=== Reports ===
* 2026-08-16, mikerm, 9406-170, Zulu firmware 2026-08-07. Trying to install V4R4 on the Zulu emulated DASD. Disk was created with <code>dd if=/dev/zero of=HD6.img bs=522 count=17177940 status=progress</code><ref>Per directions of one of the firmware developers.</ref>
** First try, ''prefetch'' setting at default (8k): halts at <code>B1934505</code> after IPL takes place from DASD
** Second try, ''prefetch'' set to 0: <code>B6080801</code> after IPL takes place from DASD. More progress, and much quicker LIC install, though.
** Configuration file used:
[SCSI]
LogModeData = 1
System = AS400_BS522

== See also ==
* [[Ordinary Harddisks on the AS/400]]
* [[Tape Drives on old AS/400]]
* [[SRC]], aka System Reference Code

== Weblinks ==
* [https://zuluscsi.com ZuluSCSI Website] — see the <tt>☰</tt> button top right for more details
* [https://github.com/ZuluSCSI/ZuluSCSI-firmware ZuluSCSI-firmware], GitHub

== Footnotes ==
<references />

[[Category:Hardware Configuration Guide]]

ZuluSCSI

2026-08-16T21:26:21Z

PoC: /* Examples */ typo

'''ZuluSCSI''' by Rabbit Hole Computing is a comparatively new family of SCSI device emulators featuring an SD card based backing store. Distinct features to older, similar devices is support for Wide-SCSI, Ultra-Speed, and a fast CPU.

ZuluSCSI also features an OpenSource firmware, so it can be extended comparatively easily.

__TOC__

For most AS/400 machines, you actually want a ZuluSCSI wide, because it offers the best performance.

The ZuluSCSI firmware can emulate multiple devices at once. There is no real need to add multiple Zulus to a given SCSI bus. One Zulu can easily saturate even the UltraWide SCSI bus of a 9401-150, and due to the SD card, delays are minimal. You can gain more performance with bigger machines, if they have multiple SCSI buses, though.

== Hardware overview ==
Depending on the exact model, boards themselves have three DIP switches and tiny push buttons:
* 1: switch to initator mode,
* 2: enable debug log,
* 3: enable SCSI termination.

The push buttons call the functions:
* Bootloader, for firmware-recovery,
* Eject.

Also, three LEDs are provided, for indication of
* 2.8 V power OK,
* 3.3 V power OK,
* SD-card activity.

The device itself needs 5 V power, and can be powered by:
* the USB port,
* the termpower line of the SCSI bus,
* molex style power connectors.

Usually, the integrated USB port is configured as USB modem, for usage with a terminal emulator. You can use the Linux or macOS ''screen'' command for that. Depending on your operating system, you need to find out what device file is created when plugging the Zulu's USB port. On Linux, it's <tt>/dev/ttyACM''n''</tt> — ''n'' being a digit, usually 0. On macOS, it's <tt>/dev/tty.usbmodem*</tt>, with a row of digits appended on behalf of the <tt>*</tt>.

The firmware presents a simple menu driven UI for

There is no need to shut down the device itself, it's safe to "pull the plug" when there is no activity. The Operating System running on the attached computer should, though.

== Configuration ==
Configuration itself is usually automatic, according to the files and directories found on the SD card. The SD card has either a FAT32<ref>Limiting files to max. 4 GiB in size</ref> or exFAT file system, the firmware understands both. It's easier to use the SD card with a card reader on a newer computer to create configurations, and files. The SD card is hotplug capable, and upon reinsertation, the ZuluSCSI reinitializes itself according to the SD card's content.

Three devices classes are of general interest in the AS/400 world:
* Disk (DASD),
* CD/DVD (Optical),
* Tape.

=== Files ===
File names are composed as follows:
<nowiki><TT><ID>[any text].<ext></nowiki>
^^ ^
| +-------------- SCSI ID character (byte offset 2)
+------------------- two-character type prefix (case-insensitive)

* '''TT''':
:{|class="wikitable"
!TT
!Device type
!Default block size
|-
|HD
|Hard disk (fixed)
|align="right"|512 Bytes
|-
|CD
|CD-ROM (optical)
|align="right"|2048 Bytes
|-
|TP
|Sequential (tape)
|align="right"|512 Bytes
|}
* The '''ID''' is exactly one char, and must be given in hexadecimal. This matters only for IDs ≥ 10.
* '''any text''' is entirely optional.
* The '''file extension''' doesn't matter.

=== Directories ===
For a device usually allowing dynamic addition and removal of media — CD-ROM-, and tape drives. The naming scheme follows the same structure as files, but ''[any text]'' must be omitted.

Files within the directories can be freely named, and are used in alphabetical order.<ref>Either through the ''Eject'' button, or the media menu.</ref>

=== Configuration file ===
In addition, a configuration file can be supplied to provide additional information to either all or one emulated device. Having a ''zuluscsi.ini'' is normally optional, but for enabling AS/400 quirks, it's mandatory.

The configuration file must be named ''zuluscsi.ini'', and is in a simple ini-style format. It has a global <tt>[SCSI]</tt> section to apply settings to all devices, and <tt>[SCSI''n'']</tt>, where ''n'' is the ID of the given SCSI devices.

== Examples ==
These are in the scope of AS/400.

=== Tape drive support ===
* create directory <code>TP0</code>,
* populate with one or more 0 byte files named <code>*.tap</code> files, e. g. by using the Unix <code>touch</code>,
* use the serial console to attach image(s) to the drive.
* ''zuluscsi.ini'':
[SCSI]
System="AS400_PPC"

[SCSI0]
TapeDensity = 0x25

Caveats:
* When you choose an image file through the USB port's media menu, make sure that you not only choose an image file, but afterwards ''insert'' it!
* If you replace a hardware tape drive, make sure to delete your old tape device file first, then IPL, check/set the new device name in DST, and have auto-configuration create the new device file during the following IPL.

This configuration has been tested on a 9401-150 running V4R5 over the course of multiple weeks:
* Occasional <tt>go save</tt> 21,
* daily differential backups,
* occasional single file restores.

== Current state ==
In the scope of AS/400's, ZuluSCSI's disk support is still incomplete, while CD- and tape emulation are seemingly solid. Some progress has been made, but there are still some rough edges, normally leading to crash of the Operating System with a given ''System Reference Code''.

At the moment, the firmware supports only a single AS/400 specific DASD device type for PPC-AS (522 Bytes per sector).

=== Reports ===
* 2026-08-16, mikerm, 9406-170, Zulu firmware 2026-08-07. Trying to install V4R4 on the Zulu emulated DASD. Disk was created with <code>dd if=/dev/zero of=HD6.img bs=522 count=17177940 status=progress</code><ref>Per directions of one of the firmware developers.</ref>
** First try, ''prefetch'' setting at default (8k): halts at <code>B1934505</code> after IPL takes place from DASD
** Second try, ''prefetch'' set to 0: <code>B6080801</code> after IPL takes place from DASD. More progress, and much quicker LIC install, though.
** Configuration file used:
[SCSI]
LogModeData = 1
System = AS400_BS522

== See also ==
* [[Ordinary Harddisks on the AS/400]]
* [[Tape Drives on old AS/400]]
* [[SRC]], aka System Reference Code

== Weblinks ==
* [https://zuluscsi.com ZuluSCSI Website] — see the <tt>☰</tt> button top right for more details
* [https://github.com/ZuluSCSI/ZuluSCSI-firmware ZuluSCSI-firmware], GitHub

== Footnotes ==
<references />

[[Category:Hardware Configuration Guide]]

ZuluSCSI

2026-08-16T21:25:30Z

PoC: Expanded article

'''ZuluSCSI''' by Rabbit Hole Computing is a comparatively new family of SCSI device emulators featuring an SD card based backing store. Distinct features to older, similar devices is support for Wide-SCSI, Ultra-Speed, and a fast CPU.

ZuluSCSI also features an OpenSource firmware, so it can be extended comparatively easily.

__TOC__

For most AS/400 machines, you actually want a ZuluSCSI wide, because it offers the best performance.

The ZuluSCSI firmware can emulate multiple devices at once. There is no real need to add multiple Zulus to a given SCSI bus. One Zulu can easily saturate even the UltraWide SCSI bus of a 9401-150, and due to the SD card, delays are minimal. You can gain more performance with bigger machines, if they have multiple SCSI buses, though.

== Hardware overview ==
Depending on the exact model, boards themselves have three DIP switches and tiny push buttons:
* 1: switch to initator mode,
* 2: enable debug log,
* 3: enable SCSI termination.

The push buttons call the functions:
* Bootloader, for firmware-recovery,
* Eject.

Also, three LEDs are provided, for indication of
* 2.8 V power OK,
* 3.3 V power OK,
* SD-card activity.

The device itself needs 5 V power, and can be powered by:
* the USB port,
* the termpower line of the SCSI bus,
* molex style power connectors.

Usually, the integrated USB port is configured as USB modem, for usage with a terminal emulator. You can use the Linux or macOS ''screen'' command for that. Depending on your operating system, you need to find out what device file is created when plugging the Zulu's USB port. On Linux, it's <tt>/dev/ttyACM''n''</tt> — ''n'' being a digit, usually 0. On macOS, it's <tt>/dev/tty.usbmodem*</tt>, with a row of digits appended on behalf of the <tt>*</tt>.

The firmware presents a simple menu driven UI for

There is no need to shut down the device itself, it's safe to "pull the plug" when there is no activity. The Operating System running on the attached computer should, though.

== Configuration ==
Configuration itself is usually automatic, according to the files and directories found on the SD card. The SD card has either a FAT32<ref>Limiting files to max. 4 GiB in size</ref> or exFAT file system, the firmware understands both. It's easier to use the SD card with a card reader on a newer computer to create configurations, and files. The SD card is hotplug capable, and upon reinsertation, the ZuluSCSI reinitializes itself according to the SD card's content.

Three devices classes are of general interest in the AS/400 world:
* Disk (DASD),
* CD/DVD (Optical),
* Tape.

=== Files ===
File names are composed as follows:
<nowiki><TT><ID>[any text].<ext></nowiki>
^^ ^
| +-------------- SCSI ID character (byte offset 2)
+------------------- two-character type prefix (case-insensitive)

* '''TT''':
:{|class="wikitable"
!TT
!Device type
!Default block size
|-
|HD
|Hard disk (fixed)
|align="right"|512 Bytes
|-
|CD
|CD-ROM (optical)
|align="right"|2048 Bytes
|-
|TP
|Sequential (tape)
|align="right"|512 Bytes
|}
* The '''ID''' is exactly one char, and must be given in hexadecimal. This matters only for IDs ≥ 10.
* '''any text''' is entirely optional.
* The '''file extension''' doesn't matter.

=== Directories ===
For a device usually allowing dynamic addition and removal of media — CD-ROM-, and tape drives. The naming scheme follows the same structure as files, but ''[any text]'' must be omitted.

Files within the directories can be freely named, and are used in alphabetical order.<ref>Either through the ''Eject'' button, or the media menu.</ref>

=== Configuration file ===
In addition, a configuration file can be supplied to provide additional information to either all or one emulated device. Having a ''zuluscsi.ini'' is normally optional, but for enabling AS/400 quirks, it's mandatory.

The configuration file must be named ''zuluscsi.ini'', and is in a simple ini-style format. It has a global <tt>[SCSI]</tt> section to apply settings to all devices, and <tt>[SCSI''n'']</tt>, where ''n'' is the ID of the given SCSI devices.

== Examples ==
These are in the scope of AS/400.

=== Tape drive support ===
* create directory <code>TP0</code>,
* populate with one or more 0 byte files named <code>*.tap</code> files, e. g. by using the Unix <code>touch</command>,
* use the serial console to attach image(s) to the drive.
* ''zuluscsi.ini'':
[SCSI]
System="AS400_PPC"

[SCSI0]
TapeDensity = 0x25

Caveats:
* When you choose an image file through the USB port's media menu, make sure that you not only choose an image file, but afterwards ''insert'' it!
* If you replace a hardware tape drive, make sure to delete your old tape device file first, then IPL, check/set the new device name in DST, and have auto-configuration create the new device file during the following IPL.

This configuration has been tested on a 9401-150 running V4R5 over the course of multiple weeks:
* Occasional <tt>go save</tt> 21,
* daily differential backups,
* occasional single file restores.

== Current state ==
In the scope of AS/400's, ZuluSCSI's disk support is still incomplete, while CD- and tape emulation are seemingly solid. Some progress has been made, but there are still some rough edges, normally leading to crash of the Operating System with a given ''System Reference Code''.

At the moment, the firmware supports only a single AS/400 specific DASD device type for PPC-AS (522 Bytes per sector).

=== Reports ===
* 2026-08-16, mikerm, 9406-170, Zulu firmware 2026-08-07. Trying to install V4R4 on the Zulu emulated DASD. Disk was created with <code>dd if=/dev/zero of=HD6.img bs=522 count=17177940 status=progress</code><ref>Per directions of one of the firmware developers.</ref>
** First try, ''prefetch'' setting at default (8k): halts at <code>B1934505</code> after IPL takes place from DASD
** Second try, ''prefetch'' set to 0: <code>B6080801</code> after IPL takes place from DASD. More progress, and much quicker LIC install, though.
** Configuration file used:
[SCSI]
LogModeData = 1
System = AS400_BS522

== See also ==
* [[Ordinary Harddisks on the AS/400]]
* [[Tape Drives on old AS/400]]
* [[SRC]], aka System Reference Code

== Weblinks ==
* [https://zuluscsi.com ZuluSCSI Website] — see the <tt>☰</tt> button top right for more details
* [https://github.com/ZuluSCSI/ZuluSCSI-firmware ZuluSCSI-firmware], GitHub

== Footnotes ==
<references />

[[Category:Hardware Configuration Guide]]

ZuluSCSI

2026-08-16T19:56:28Z

PoC: Moore precise

'''ZuluSCSI'' is a comparatively new family of SCSI device emulators. Distinct features to older, similar devices is support for Wide-SCSI, Ultra-Speed, and a fast CPU.

ZuluSCSI also features an OpenSource firmware, so it can be extended comparatively easily.

__TOC__

== Current state ==
In the scope of AS/400's, ZuluSCSI's disk support is still in its infancy, while CD- and tape emulation are seemingly solid. Some progress has been made, but there are still some rough edges, normally leading to crash of the Operating System with a given ''System Reference Code''.

At the moment, the firmware supports only a single DASD device type.

=== Reports ===
* 2026-08-16, mikerm, 9406-170, Zulu firmware 2026-08-07. Trying to install V4R4 on the Zulu emulated DASD. Disk was created with <code>dd if=/dev/zero of=HD6.img bs=522 count=17177940 status=progress</code><ref>Per directions of one of the firmware developers.</ref>
** First try, ''prefetch'' setting at default (8k): halts at <code>B1934505</code> after IPL takes place from DASD
** Second try, ''prefetch'' set to 0: <code>B6080801</code> after IPL takes place from DASD. More progress, and much quicker LIC install, though.
** Configuration file used:
[SCSI]
LogModeData = 1
System = AS400_BS522

== See also ==
* [[Ordinary Harddisks on the AS/400]]
* [[Tape Drives on old AS/400]]
* [[SRC]], aka System Reference Code

== Weblinks ==
* [https://zuluscsi.com ZuluSCSI Website] — see the <tt>☰</tt> button top right for more details
* [https://github.com/ZuluSCSI/ZuluSCSI-firmware ZuluSCSI-firmware], GitHub

== Footnotes ==
<references />

[[Category:Hardware Configuration Guide]]

ZuluSCSI

2026-08-16T19:49:26Z

PoC: Preliminary

'''ZuluSCSI'' is a comparatively new family of SCSI device emulators. Distinct features to older, similar devices is support for Wide-SCSI, Ultra-Speed, and a fast CPU.

ZuluSCSI also features an OpenSource firmware, so it can be extended comparatively easily.

__TOC__

== Current state ==
In the scope of AS/400's, ZuluSCSI's disk support is still in its infancy. Some progress has been made, but there are still some rough edges, normally leading to crash of the Operating System with a given ''System Reference Code''.

At the moment, the firmware supports only a single DASD device.

=== Reports ===
* 2026-08-16, mikerm, 9406-170, Zulu firmware 2026-08-07. Trying to install V4R4 on the Zulu emulated DASD.
** First try, ''prefetch'' setting at default (8k): halts at <code>B1934505</code>
** Second try, ''prefetch'' set to 0: <code>B6080801</code>. More progress, and much quicker LIC install, though.

== See also ==
* [[Ordinary Harddisks on the AS/400]]
* [[Tape Drives on old AS/400]]
* [[SRC]], aka System Reference Code

== Weblinks ==
* [https://zuluscsi.com ZuluSCSI Website] — see the <tt>☰</tt> button top right for more details
* [https://github.com/ZuluSCSI/ZuluSCSI-firmware ZuluSCSI-firmware], GitHub

[[Category:Hardware Configuration Guide]]

System Internals:SLIC DASD device recognition

2026-08-16T19:22:48Z

PoC: ±Cat/AI heading

{{AI generated not reviewed}}
The '''SLIC DASD device recognition''' table is the static list, inside the OS/400 Licensed Internal Code (SLIC), of which SCSI disk drives the system will accept as a DASD (disk) unit. This page describes how that recognition works, how to find and decode the table in a SLIC image, and — as a worked example — the complete list a V4R4 machine accepts. The method generalises to any release and to other SLIC device tables.

Understanding it matters for preservation: OS/400 refuses ordinary SCSI disks, so keeping a machine alive after a disk failure means presenting a drive (real or emulated) that answers the SCSI bus the way SLIC expects.

== How SLIC decides a disk is acceptable ==

A disk becomes an eligible DASD unit only if it passes three independent gates, all implemented in the SLIC disk device driver:

# '''SCSI INQUIRY must match a static table.''' SLIC compares the drive's INQUIRY vendor id (bytes 8–15) and product id (bytes 16–31) against a built-in table. Only IBM-badged units qualify: the vendor id is normally <code>IBMAS400</code> (a handful of early units use <code>IBM␠␠␠␠␠</code> and two OEM units use <code>QUANTUM␠</code>). An off-the-shelf drive reports its own vendor and is rejected. This is exactly what the "custom firmware" on IBM's 660x/671x disks does: IBM reflashed standard Ultrastar/Corsair mechanisms to answer INQUIRY with an IBM vendor id and an IBM product id.
# '''Vendor-unique SKIP READ / SKIP WRITE.''' The driver issues IBM vendor-unique SCSI commands that read or write a run of sectors while skipping masked ones, used by the Single-Level Store paging path. A faithful drive must implement these, not just standard READ/WRITE.
# '''Capacity from VPD.''' The unit's size is taken at run time from the drive's Vital Product Data / <code>READ CAPACITY</code>, not from the table — the table has no capacity column. An impersonating drive must report a capacity that is legal for the feature type it claims.

== Finding and decoding the table ==

In a SLIC image the table is a run of fixed-size records. On V4R4 each record is 40 bytes:

<pre>
bytes 0- 3 feature type EBCDIC digits, e.g. F6F6F0F7 = "6607"
bytes 4- 5 model EBCDIC, e.g. "1 "
byte 6 class flag 0x00 normal; 0x80 on the 18 GB Ultra2/LVD units
bytes 7-15 reserved 0x40 (EBCDIC space) padding
bytes 16-23 INQUIRY vendor ASCII, matched against INQUIRY bytes 8-15
bytes 24-39 INQUIRY product ASCII, matched against INQUIRY bytes 16-31
</pre>

The type and model are EBCDIC (digit ''n'' = byte <code>0xF''n''</code>); the INQUIRY strings are ASCII. To locate the table, search the image for the ASCII vendor strings <code>IBMAS400</code> / <code>QUANTUM␠</code>: the records sit at a fixed 40-byte stride around them. The same trick — anchor on a known ASCII string, then read the fixed-width record around it — recovers other SLIC hardware tables (IOP/controller CCIN tables, adapter tables, and so on).

== The V4R4 list ==

Every drive a V4R4 system accepts, decoded from the image. "Physical drive" is identification from IBM/Quantum model nomenclature, not read from the binary; the feature type, model and INQUIRY strings are.

{| class="wikitable"
! Feature/Model !! INQUIRY vendor !! INQUIRY product !! Physical drive
|-
| 6109 / 0 || <code>IBM␠␠␠␠␠</code> || <code>0663H12</code> || IBM 0663 "Corsair", ~2 GB
|-
| 6109 / 1 || <code>IBM␠␠␠␠␠</code> || <code>0661371</code> || IBM 0661 "Pixie", ~0.37 GB
|-
| 6105 / 0 || <code>IBM␠␠␠␠␠</code> || <code>0661467</code> || IBM 0661 "Pixie", ~0.47 GB
|-
| 6107 / 0 || <code>IBMAS400</code> || <code>0664M1H</code> || IBM 0664 "Corsair-4", ~4 GB
|-
| 6603 / 0 || <code>IBMAS400</code> || <code>0664N1H</code> || IBM 0664 "Corsair-4", ~4 GB
|-
| 6603 / 1 || <code>IBMAS400</code> || <code>0662S12</code> || IBM 0662 "Corsair", ~1.2 GB
|-
| 6602 / 0 || <code>IBMAS400</code> || <code>0662SW1</code> || IBM 0662 "Corsair", ~1.0 GB
|-
| 6602 / 1 || <code>IBMAS400</code> || <code>DFHSS1W</code> || IBM Ultrastar XP, ~1 GB
|-
| 6605 / 1 || <code>IBMAS400</code> || <code>DFHSS2W</code> || IBM Ultrastar XP, ~2 GB
|-
| 6606 / 1 || <code>IBMAS400</code> || <code>DFHSS4W</code> || IBM Ultrastar XP, ~4 GB
|-
| '''6607 / 1''' || <code>IBMAS400</code> || <code>DCHS09W</code> || IBM Ultrastar 2XP, ~9 GB
|-
| 6713 / 1 || <code>IBMAS400</code> || <code>DGHS18U</code> || IBM Ultrastar 18XP, ~18 GB
|-
| 6714 / 1 || <code>IBMAS400</code> || <code>DGVS09U</code> || IBM Ultrastar 9ES/9LZX, ~9 GB
|-
| 6717 / 1 || <code>QUANTUM␠</code> || <code>SSQD107</code> || Quantum, ~10.7 GB
|-
| 6730 / 0 || <code>QUANTUM␠</code> || <code>SSQD160</code> || Quantum, ~16.0 GB
|-
| 6731 / 0 || <code>IBMAS400</code> || <code>DRVS18D</code> || IBM Ultrastar 18ES/18LZX, ~18 GB, Ultra2/LVD
|}

Feature-type numbers do not track capacity linearly: the type encodes the AS/400 usable-capacity class (after 520-byte-sector overhead), not the drive's native size. The much-cited 6607 is here as <code>IBMAS400</code> / <code>DCHS09W</code>.

== Notes ==

* "Ide" in SLIC symbol names (e.g. the driver classes handling these disks) is the disk device-driver namespace, '''not''' ATA/IDE.
* Numbers like 2748, 6502, 6512, 6751, 6753, 6754 that appear on other SLIC symbols are IOP / disk-controller CCINs, not drive models.
* An emulated target (for example on open SCSI-emulator firmware) must present one of the vendor+product pairs above verbatim, space-padded to the SCSI field widths, implement the vendor-unique SKIP commands, and report a legal capacity via <code>READ CAPACITY</code>.

[[Category:System Internals]]

System Files:QFILEMCD

2026-08-16T19:22:17Z

PoC: ±Cat/AI heading

{{AI generated not reviewed}}
'''<code>QFILEMCD</code>''' is the larger of the two container files found on AS/400 SAVSYS and Licensed Internal Code installation media. It is a backup of '''SLIC''' itself — the System Licensed Internal Code that sits below OS/400 — stored as a small number of very large memory segments. Its internal format is called '''<code>COPYDIR</code>''' after the eyecatcher at offset zero.

Practically, this is the file to reach for if you want to read the machine's own code without touching a running system. Its segments are a byte-for-byte image of what the link loader maps into memory, so an address recovered from a crash, a trace or a [[SRC|system reference code]] can be looked up directly in a file on your workstation. The companion file [[System Files:QFILEIML]] carries the loadable IOP, adapter and service processor microcode instead.

Both files are containers of [[Data Structures:LID|LIDs]], but at different granularities, and the relationship between them is described under ''Two directories, two granularities'' below.

The figures quoted here come from one V4R4 image of 472,846,336 bytes (451 MiB). Treat structure as general and numbers as release-specific; the format is unchanged from V4R4 through V7R4, across install media and SAVSYS output alike.

== Header ==
{|class="wikitable"
!Offset
!Contents
|-
|<code>0x00</code>
|Eyecatcher <code>COPYDIR </code> in EBCDIC (<code>C3 D6 D7 E8 C4 C9 D9 40</code>), a zero byte, then the two EBCDIC characters <code>00</code>
|-
|<code>0x1C</code>
|32-bit total size of the payload area — see below. Confirmed on three independent samples
|-
|<code>0x26</code>
|Release level, then the '''system serial number''', EBCDIC
|-
|<code>0x50</code>
|Licensed Internal Code banner, EBCDIC, in 48-character chunks
|-
|<code>0x1C0</code>
|Start of the directory
|}

The string in a V4R4 image reads:

<pre>
V4R4M044-C6295 2606071417
</pre>

and in a V7R4 one taken by SAVSYS from a running machine:

<pre>
V7R4M021-7886W
</pre>

The first field is the release and modification level. '''The five characters after the hyphen are the system serial number.''' That is not an inference: the owner of the V7R4 machine confirms its serial is <code>7886W</code>.

On '''installation media''' the same field carries a build or media tag instead — a V7R4 install ISO reads <code>V7R4M021-821BV</code> — so what the field means depends on how the image was produced. Both forms are five characters, which makes them easy to confuse.

<blockquote>'''Note!''' A LIC backup is therefore '''not anonymous''': it records the serial number of the machine it came from. The serial is also one of the values the system password is keyed on (see [[CISC AS/400 LIC Tapes]]), so treat these files as identifying if you share them.</blockquote>

In the V4R4 sample the ten digits after the serial parse naturally as a timestamp of the form <code>YYMMDDHHMM</code>, making that backup 2026-06-07 14:17. That part '''is''' an inference from the shape of the field, and the V7R4 sample carries binary rather than digits in the same place, so the layout after the serial is not fixed.

<blockquote>'''Note!''' The header is '''not''' a fixed 192 (<code>0xC0</code>) bytes, despite older format notes saying so. The IBM legal banner runs on well past that point, and in this V4R4 image the directory does not begin until <code>0x1C0</code>. A parser should locate the directory by scanning for the first 64-byte-aligned block that has the shape of an entry, rather than seeking to a constant.</blockquote>

The 32-bit field at <code>0x1C</code> holds <code>0x1C2F0000</code>, which is exactly the end of the last segment's data. It is a total-payload-size field and makes a good consistency check after parsing the directory: accumulate the entries and you should arrive at the same number.

== The directory ==
The directory is a run of 64-byte entries beginning at <code>0x1C0</code>.

{|class="wikitable"
!Offset
!Size
!Field
|-
|<code>+0x00</code>
|8
|Always zero in observed data
|-
|<code>+0x08</code>
|8
|Flags. See the bit-numbering warning below
|-
|<code>+0x10</code>
|8
|SLS address of the saved segment
|-
|<code>+0x18</code>
|8
|Segment attributes; the top 16 bits carry the useful value
|-
|<code>+0x20</code>
|8
|Always zero in observed data
|-
|<code>+0x28</code>
|8
|Offset to the segment data, '''absolute from the start of the file'''
|-
|<code>+0x30</code>
|4
|Segment length, in '''raw bytes''' — not blocks
|-
|<code>+0x34</code>
|4
|Always zero in observed data
|-
|<code>+0x38</code>
|8
|Always zero in observed data
|}

Two details cause most of the trouble people have with this structure, and both were originally got wrong here:

* '''Flags use IBM's MSB-first bit numbering.''' Older notes describe the field as <code>bbt 0:3</code>, and a reader used to LSB-first numbering will look in the bottom nibble and find nothing. Bit 0 is the ''most'' significant bit, so the value lives in the '''top''' nibble of the 8-byte field. A normal entry reads <code>0x1000000000000000</code>; the end-of-directory marker reads <code>0xF000000000000000</code>.
* '''The data offset is absolute.''' It is measured from the start of the file, not from the end of the directory. Reading it as relative shifts every extracted segment by the size of the directory, which produces code that disassembles almost plausibly and is wrong everywhere.

In this image the directory holds '''32 entries''', with the terminator at <code>0x9C0</code> and the directory ending at <code>0xA00</code>. The first entry has a data offset of zero, which means the header and directory physically occupy the first <code>0xA00</code> bytes of the first segment's stored image. This is expected rather than a bug, but a tool that extracts that segment will see the container's own header at the front of it.

Segment lengths are consistently a whole number of 4 KiB pages less than a power-of-two boundary: <code>0xFFF000</code> is 16 MiB minus one page, <code>0x7FF000</code> is 8 MiB minus one page, and so on.

== Contents of a typical backup ==
The 32 segments of this image, with names from a community-maintained SLS address reference. Where the name column is blank, the segment's purpose has not been established.

{|class="wikitable"
!SLS address
!Length
!Name
|-
|<code>FFFFFFFFB1 000000</code>
|16 MiB
|
|-
|<code>FFFFFFFFB2 000000</code>
|16 MiB
|
|-
|<code>FFFFFFFFB3 000000</code>
|16 MiB
|
|-
|<code>FFFFFFFFB5 000000</code>
|16 MiB
|
|-
|<code>FFFFFFFFC1 000000</code>
|16 MiB
|Link Loader — LIC Code
|-
|<code>FFFFFFFFC2 000000</code>
|16 MiB
|Link Loader — LIC Data
|-
|<code>FFFFFFFFC3 000000</code>
|16 MiB
|Link Loader — LIC Code (2)
|-
|<code>FFFFFFFFC4 000000</code>
|16 MiB
|Link Loader — LIC Code (3)
|-
|<code>FFFFFFFFC5 000000</code>
|16 MiB
|Link Loader — LIC Code (4)
|-
|<code>FFFFFFFFC6 000000</code>
|8 MiB
|Link Loader — LIC Code (5)
|-
|<code>FFFFFFFFC7 000000</code>
|16 MiB
|Mixed — component code and NLS text pools
|-
|<code>FFFFFFFFC8 000000</code>
|8 MiB
|Mixed — bignum/JVM code and NLS text pools
|-
|<code>FFFFFFFFF1 000000</code>
|4 MiB
|Link Loader TOC
|-
|<code>FFFFFFFFF2 000000</code>
|16 MiB
|Service LID
|-
|<code>FFFFFFFFF4 000000</code>
|16 MiB
|Service LID (2)
|-
|<code>FFFFFFFFFE 000000</code>
|15 MiB
|Pageable BLA
|-
|<code>FFFFFFFFD1 000000</code>
|16 MiB
|Link Loader Information
|-
|<code>FFFFFFFFD2 000000</code>
|16 MiB
|Link Loader Information, Code, Data
|-
|<code>FFFFFFFFD3 000000</code>
|16 MiB
|Link Loader Information (2)
|-
|<code>FFFFFFFFD4 000000</code>
|16 MiB
|Mixed — JVM strings and DST debug symbol table
|-
|<code>FFFFFFFF90 010000</code>
|60 KiB
|LID Directory
|-
|<code>FFFFFFFF91 000000</code>
|16 MiB
|LID NUC2 A-Side
|-
|<code>FFFFFFFF92 000000</code>
|16 MiB
|LID NUC2 B-Side
|-
|<code>FFFFFFFF93 000000</code>
|16 MiB
|LID NUC1 A-Side
|-
|<code>FFFFFFFF94 000000</code>
|16 MiB
|LID NUC1 B-Side
|-
|<code>FFFFFFFF95 000000</code>
|16 MiB
|
|-
|<code>FFFFFFFF96 000000</code>
|16 MiB
|
|-
|<code>FFFFFFFF9A 000000</code>
|8 MiB
|
|-
|<code>FFFFFFFF9B 000000</code>
|8 MiB
|
|-
|<code>FFFFFFFFA1 000000</code>
|16 MiB
|LID Manager
|-
|<code>FFFFFFFFA2 000000</code>
|16 MiB
|
|-
|<code>FFFFFFFF69 000000</code>
|16 MiB
|IDE
|}

So a backup of this shape is the SLIC boot and loader nucleus: link loader code and data, the loader's table of contents, the LID subsystem's own bookkeeping, and both IPL sides of the two nucleus LIDs. It is not the whole of the machine's code.

=== A and B sides ===
Several segments appear twice, distinguished as ''A-side'' and ''B-side''. An AS/400 keeps two copies of its Licensed Internal Code so that an update can be applied to one while the other remains a fallback. A normal, unattended IPL runs the '''B side''', so B is what a running machine is executing and B is what static analysis should be done against. Because the two sides are normally near-identical, a byte comparison against the A side is not evidence that A is the live one — the test only means something on a segment that actually differs between them.

== Two directories, two granularities ==
A common source of confusion is that <code>QFILEMCD</code> appears to have two completely different directory formats. It does, and they nest:

* The '''coarse''' level is <code>COPYDIR</code>'s own directory, documented above: 64-byte entries, one per 16 MiB-class memory segment, 32 of them.
* The '''fine''' level is a catalogue of individual LIDs, thousands of entries, using the 32-byte record described at [[Data Structures:LID]].

The fine level is not a second header in the file. It is simply '''the contents of one particular segment''' — the one named ''LID Directory'', at <code>FFFFFFFF90 010000</code>. Extract that segment and you find, after a preamble of about 1536 bytes, an EBCDIC <code>Directory.</code> eyecatcher, a version label, and then the records. In this image the label reads <code>v4r4m01204.0.03</code>, which is the same label carried by [[System Files:QFILEIML]] — a quick way to confirm that two files came off the same media.

That is also why tools which dump this file emit two dissimilar-looking listings: a short table of large memory extents, and a long list of LIDs. They are two levels of one structure, not two formats.

== Extracting a segment ==
The practical recipe, and the reason this file is worth knowing about:

# Read the <code>COPYDIR</code> eyecatcher at offset 0 to confirm the format.
# Find the directory by scanning 64-byte-aligned offsets for the first entry-shaped block, rather than assuming <code>0xC0</code> or <code>0x1C0</code>.
# Walk entries until the flags field has <code>0xF</code> in its '''top''' nibble.
# For the segment you want, seek to the data offset '''as an absolute file offset''' and read ''length'' raw bytes.
# Load the result at its SLS address in a disassembler. The bytes are what the link loader maps, so addresses match.

Step 5 is the payoff. A 64-bit address such as <code>FFFFFFFFC6 1F1690</code> can be typed straight into the DST ''Display/Alter storage'' panel on a live machine of the same build, and the sixteen rows it displays will match the extracted file byte for byte. Static and live analysis share one address space, which means you can do the slow work offline and use the machine only for confirmation.

Two caveats on addresses. They are per-'''build''', not per-release, so comparisons are only meaningful between identical builds; the same class sits at a quite different address on a V5R4 machine. And the SLS address recorded in the directory is the address the segment was '''saved from''', which is not always where it runs — the resident nucleus segment, for instance, is stored in the container under the SID of the B-side nucleus LID rather than its runtime SID.

== Reading the code ==
Once a segment is loaded, two structures make it navigable, and both are worth knowing because they turn addresses into names:

* '''Traceback trailers.''' Every compilation unit ends its code with a <code>TBTB</code> trailer, and many carry the module's name. A trailer names a whole compilation unit rather than a single function, so a hit means "this address is inside module X", not "this address is function X".
* '''Link-loader descriptor blocks.''' Considerably richer: one block per procedure, carrying the entry address at <code>+0x08</code> and the name in EBCDIC at <code>+0x38</code>. Names beginning with <code>#</code> are SLIC-internal modules; the rest are C++ mangled symbols.

Merging both across every segment of this V4R4 image yields roughly 184,000 named records, which is enough to name a substantial fraction of any address you encounter. See [[SRC]] for how to use that to get from a reference code back to a module.

Calls between modules do not go through a conventional dispatch table, which surprises people disassembling SLIC for the first time. An external call is a two-instruction sequence — <code>ori r11,r13,''ordinal''</code> followed by <code>bla</code> into a transfer vector at the very top of the address space — and the 16-byte stub it lands on computes the target arithmetically. There is no table to read off; the ordinal ''is'' the callee's word offset within a window, and the stub supplies the window. The stub constants cannot be derived and must be read from a dump of the transfer vector.

== The trailing page ==
The payload area ends at <code>0x1C2F0000</code>, but the file is one 4 KiB page longer than that. The final page is not padding: it holds 468 non-zero 8-byte records, which appear to be address-and-value pairs.

They fall into two clear populations. The first 110 are in ascending address order with a value of 8, addressing the ''Link Loader — LIC Data'' segment among others. The remaining 256 are identical to each other: the same address <code>0xFE911220</code>, in the ''Pageable BLA'' segment, paired with the value <code>0x48000002</code> — which as PowerPC is a branch-absolute to zero, the shape of a deliberately poisoned entry.

This has the flavour of a fixup or relocation list applied after the segments are restored, but that is a guess from shape alone. It is recorded here because it is real, reproducible and unexplained, and because a parser that assumes the file ends with the payload will silently ignore it.

== Open questions ==
* The purpose of the trailing page.
* The header bytes other than the eyecatcher, size field, release string and banner.
* The meaning of the segment attribute field's top 16 bits, which take values <code>0x0001</code>, <code>0x0040</code>, <code>0x0080</code> and <code>0x0100</code> and correlate loosely with segment size.
* Names for the nine segments left blank in the table above.

== See also ==
* [[System Files:QFILEIML]]
* [[Data Structures:LID]]
* [[SRC]]
* [[CISC AS/400 LIC Tapes]]

[[Category: System Internals]]

System Files:QFILEIML

2026-08-16T19:21:56Z

PoC: ±Cat/AI heading

{{AI generated not reviewed}}
'''<code>QFILEIML</code>''' is one of the two large container files found on AS/400 SAVSYS and Licensed Internal Code installation media. It holds the machine's ''loadable'' microcode: IOP and adapter firmware, service processor firmware, and a quantity of SLIC modules. Its internal format is identified by the four-byte magic '''<code>IMD1</code>''' and is a container of [[Data Structures:LID|LIDs]].

The companion file <code>QFILEMCD</code> holds SLIC proper, via a directory called <code>COPYDIR</code>. Both files use the same 32-byte [[Data Structures:LID|LID directory record]], and a record present in both is byte-for-byte identical, so the two are two views of one packaging scheme rather than two unrelated formats.

The name is not documented by IBM as far as is known here. <code>IML</code> almost certainly stands for ''Initial Microprogram Load'' — the phase in which the machine's microcode is brought up, before OS/400 itself exists — which matches the file's contents. Treat the expansion as an inference.

This description is based on two samples: a V4R4 image of 81,287,680 bytes (77.5 MiB), build label <code>v4r4m01204.0.03</code>, and a V7R2 one of 288.7 MiB, label <code>v7r2m00000.0.00</code>, taken from an installation ISO. Unless a figure is attributed to a release, it comes from the V4R4 sample; the section ''Across releases'' sets out what is format and what merely happened to be true of one image.

== File layout ==
The layout is '''not at fixed offsets'''. It is carried in the header, and it differs between releases — a decoder that assumes the V4R4 offsets will read a V7R2 container as having no entries at all, without reporting an error.

The field at <code>+0x08</code>, low 24 bits, is the offset to the Licensed Internal Code banner. The directory header sits at exactly '''twice''' that offset, its records <code>0x20</code> further on, and the build label at header <code>+0x10</code>.

{|class="wikitable"
!Release
!<code>+0x08</code>
!Banner
!Directory header
!Records
!Build label
|-
|V4R4
|<code>ff000200</code>
|<code>0x200</code>
|<code>0x400</code>
|<code>0x420</code>
|<code>v4r4m01204.0.03</code>
|-
|V7R2
|<code>ff000800</code>
|<code>0x800</code>
|<code>0x1000</code>
|<code>0x1020</code>
|<code>v7r2m00000.0.00</code>
|}

So the general layout is:

{|class="wikitable"
!Offset
!Contents
|-
|<code>0x000</code>
|Magic <code>C9 D4 C4 F1</code>, which is <code>IMD1</code> in EBCDIC
|-
|<code>0x008</code>
|Low 24 bits: offset to the banner. The rest of the header is not understood
|-
|''banner''
|Licensed Internal Code banner in EBCDIC, carrying the LIC product identifiers
|-
|''banner'' × 2
|Directory header: a four-byte preamble, the literal string <code>Directory.</code>, two zero bytes, then a 16-byte build label
|-
|''banner'' × 2 + <code>0x20</code>
|The directory: a run of 32-byte LID records
|-
|''varies''
|Terminator record, identifier <code>0xC5D5C440</code> (<code>END </code> in EBCDIC)
|}

The first sixteen bytes of a V4R4 container are:

<pre>
00000000: c9d4 c4f1 0000 0000 ff00 0200 00e0 0000
</pre>

and of a V7R2 one:

<pre>
00000000: c9d4 c4f1 0000 0000 ff00 0800 0010 0000
</pre>

The banner reads, in EBCDIC:

<pre>
LICENSED INTERNAL CODE - PROPERTY OF IBM 5763999, 5716999, 5769999
(C) COPYRIGHT IBM CORP. 1980, 1998. ALL RIGHTS RESERVED. ...
</pre>

The seven-digit numbers are LIC product identifiers, and the same ones appear in <code>QFILEMCD</code>. The build label is likewise identical between the two container files from the same media, which is a convenient way to confirm that a given <code>QFILEIML</code> and <code>QFILEMCD</code> belong together.

The field at <code>+0x0C</code> differs between the two samples (<code>00e00000</code> against <code>00100000</code>) and is not understood. Two samples are not enough to fit it.

== The directory ==
The directory begins at <code>0x420</code> and runs, in this image, for 632 records before the <code>END </code> terminator at <code>0x5320</code>. The record layout is documented at [[Data Structures:LID]] and is not repeated here.

Of the 632 records:
* 341 carry the compressed flag.
* 631 name an SLS staging address in the <code>FFFFFFFFxx</code> band. Exactly one does not: LID <code>80900818</code> stages at <code>000000024A 000000</code>.
* 7 have payloads that are themselves runs of LID records — see ''Directory extents'' below.

== Payload addressing ==
<blockquote>'''Note!''' This is the single point on which it is easiest to go wrong, and doing so silently produces plausible-looking nonsense.</blockquote>

The <code>offset</code> field in each record is '''not''' an offset into the container. It is a load-source LBA, describing where the payload sits on the installation medium, and it has no useful meaning inside the file.

Reading it as a file offset is superficially attractive and definitively wrong. Doing so on a V4R4 image yields 608 overlapping extents out of 632, a maximum extent of 34,550 blocks against a 158,765-block file, and a minimum offset of block 3, which lands inside the header. That the lengths happen to sum to approximately the file size is a coincidence and should not be taken as confirmation.

The actual rule is simpler: '''payloads are stored sequentially, in directory order, immediately after the directory''', each one <code>length</code> blocks long. There are no gaps and no padding between them.

'''Payloads begin at the next 512-byte block boundary after the directory terminator.''' That is block 42 for the V4R4 sample and block 69 for the V7R2 one. This rule needs only the directory, so it also works on a container embedded in a larger image — an install ISO, for instance — where the file size is not a meaningful quantity.

An older formulation, ''file size in blocks minus the sum of all lengths'', gives the same answer for a standalone file and is a useful cross-check: on the V4R4 sample the two agree exactly, and the implied container size matches the real file size to the byte at 81,287,680. But it cannot be used on an embedded container, so prefer the terminator rule.

To locate a payload, therefore, walk the directory from the beginning and accumulate lengths; do not index by the offset field.

== Contents ==
Laid out correctly, the payloads fall into two clear populations, distinguishable without decompression by looking for 32-bit <code>stwu r1,-x(r1)</code> prologues versus 64-bit <code>std</code> stores:

{|class="wikitable"
!Population
!Count
!Identification
|-
|32-bit PowerPC
|75
|<code>stwu</code> prologues present, no <code>std</code> at all
|-
|64-bit PowerPC AS (SLIC)
|210
|<code>std</code> present, no <code>stwu</code> at all
|-
|Neither
|347
|Compressed payloads, data, tables, and directory extents
|}

The split is clean — no payload shows both — which is what makes the heuristic trustworthy. The 32-bit population is the interesting one: the main processor of these machines is 64-bit PowerPC AS, so 32-bit code in this file is by definition destined for something else. That is the IOP, adapter and service processor microcode.

=== Service processor firmware ===
LID <code>80900702</code> is service processor Licensed Internal Code: 128 KiB, stored uncompressed, staged at SLS <code>FFFFFFFF9A 001000</code>. Its EBCDIC strings include a ''9400 Licensed Internal Code'' banner and a 1998 copyright, and its code is unambiguously 32-bit.

This confirms a long-standing claim in the trade press that AS/400 service processor firmware is loaded from the load source rather than residing wholly in flash on the card. As the rest of this section shows, that turns out to be only half true.

About 30 payloads carry an <code>AJS</code> build identifier and are service-processor code, ranging from a few tens of kilobytes to a few hundred. A further handful carry <code>AJG</code> identifiers and are I/O offload (MFIOP) code instead; several of those carry an <code>ATM</code> marker, i.e. ATM networking, which is not something a service processor does. The two families are ''mostly'' disjoint but not perfectly: at least one payload contains both identifiers.

==== Module headers ====
Each of these images is not a monolithic firmware blob but a collection of '''linkable modules''', each introduced by a header with the EBCDIC eyecatcher '''<code>PGPM</code>''' (<code>D7 C7 D7 D4</code>) — 119 of them in a V4R4 container and 104 in a V7R2 one, decoding identically. The useful fields are:

{|class="wikitable"
!Offset
!Contents
|-
|<code>+0x00</code>
|<code>PGPM</code> eyecatcher
|-
|<code>+0x04</code>
|A LID identifier — but see the caveat below
|-
|<code>+0x24</code>
|EBCDIC version string, e.g. <code>0100</code>
|-
|<code>+0x30</code>
|8-byte build identifier, e.g. <code>AJSFGVB3</code>
|-
|<code>+0x54</code>
|8-byte name of the module this header '''defines'''
|-
|<code>+0x60</code>
|Slot table, 4-byte values
|-
|<code>+0xC0</code>
|Import table: 12-byte entries, each an 8-byte name and a 4-byte linkage slot, terminated by eight EBCDIC <code>F</code> characters
|}

<blockquote>'''Note!''' Strings such as <code>SP MOPT1</code>, <code>SP SPCI3</code> or <code>SP WT</code> are '''module names in a link table''', not feature or capability tags. An earlier version of this article described them as component tags whose differing sets indicated capability tiers across the hardware range. That reading was wrong: the sets differ because different modules import different things.</blockquote>

Worked example, from the header at <code>+0x59C</code> of LID <code>A07008C2</code>: build <code>AJSFGVB3</code>, defines <code>SP SB</code>, and imports <code>SP SPCI1</code> through <code>SP SPCI5</code> and <code>CUANSI</code>, with the import table running to its terminator at <code>+0x1B4</code>.

Both families share a common utility layer, which is why their vocabulary overlaps: <code>CUANSI</code>, <code>CUCONV</code>, <code>CUIO</code>, <code>CUMEMORY</code>, <code>CUMISC</code> and <code>CUSTO</code>, plus <code>SRASCOMN</code> for RAS common code.

==== Reading the dependency graph ====
Because every module declares what it defines and what it imports, the link tables can simply be read off as a dependency graph — which is more informative than any amount of disassembly, and is the main reason the <code>PGPM</code> header is worth knowing about.

Doing so reveals a clean pattern. The '''numbered''' names — <code>SP SPCI1</code> to <code>SPCI5</code>, <code>SP MOPT1</code> to <code>MOPT9</code>, <code>SP MOPD1</code> — are imported by many modules and '''defined by none'''. The '''lettered''' members of the same families — <code>MOPTA</code>, <code>MOPTB</code>, <code>MOPTC</code>, <code>MOPD2</code> — each import their immediate predecessor and are present as real modules.

The natural reading is that numbered names are resident firmware on the card and lettered ones are downloadable extensions layered on top. Which is exactly what the following section establishes by a completely independent route.

<blockquote>'''Caveat.''' The LID identifier at <code>+0x04</code> of a <code>PGPM</code> header frequently disagrees with the container LID that the sequential payload layout assigns to that region. Most of these values are valid LID identifiers from the directory, and in one region a run of 21 consecutive modules is spaced exactly by the directory lengths of the LIDs they name. Either the layout is displaced there, or modules are stored under a delivery LID distinct from their own. Findings about module ''contents'' are unaffected, since they come from the headers themselves — but do not quote a byte offset against a specific LID until this is resolved.</blockquote>

=== What is not in the file ===
Notably, the service processor's own '''supervisor is absent'''. Two independent lines of evidence agree on this.

'''From the instruction stream.''' All payloads were searched for <code>rfi</code> (<code>0x4C000064</code>), which any PowerPC exception-returning kernel must contain, and for exception vector tables at the architectural <code>0x100</code>, <code>0x200</code> and subsequent offsets of every 4 KiB boundary. Across 4.1 MB of service-processor code there is not one <code>rfi</code>, and no payload has a vector table. Privileged operations are almost as scarce: six instructions of the <code>mtmsr</code> family and four cache or TLB operations in the whole set.

Consistent with that, LID <code>80900702</code> begins mid-function, with a function ''tail'' rather than an entry point, and manipulates no privileged state at all — only LR, CTR and XER are touched. It does contain 31 <code>sc</code> supervisor calls.

'''From the link tables.''' As described above, the numbered module names are imported by many modules and defined by none. The code that provides them is therefore not on this medium.

The conclusion is that the service processor runs a resident supervisor of its own, held in flash on the card, and that this file supplies only loadable task modules that sit on top of it. That is consistent with the hardware — the operator panel carries its own flash, and SLIC has an explicit message for instructing the service processor to IPL itself.

==== The supervisor call interface ====
Since the supervisor itself is absent, the <code>sc</code> instructions are the entire visible boundary between these modules and the firmware they run on. Across the family there are 668 supervisor calls using just 9 distinct call numbers, with the number in <code>r0</code> and arguments from <code>r3</code>:

{|class="wikitable"
!Call
!Count
!Observed arguments
|-
|<code>0x020C</code>
|262
|—
|-
|<code>0x0208</code>
|131
|<code>r3 = 0x16</code> in every instance
|-
|<code>0x03A4</code>
|106
|<code>r3 = 0x64</code>, <code>r4 = 5</code>; unique to one module
|-
|<code>0x0358</code>
|
|<code>r3</code> is one of exactly three values: <code>0x83010000</code>, <code>0x83020000</code>, <code>0x83030000</code>
|}

The first two are the interesting pair: <code>0x0208</code> occurs exactly half as often as <code>0x020C</code>, and always on the same resource number, which is the signature of an acquire/release pair around a critical section. The <code>0x0358</code> window is the only region passed explicitly to a supervisor call, which is what registering or mapping a device or shared-memory window looks like.

Beyond that the call numbers cannot be decoded, because the code that implements them is not on this medium.

==== A caution about what this firmware does ====
It is tempting to assume this firmware covers the obvious service-processor duties — power control, thermal and fan management, SPCN, driving the panel and its LCD, VPD storage, error logging and SRC posting. '''No such claim is supported by this file.'''

These modules contain almost no descriptive text. The complete inventory of readable strings is the Licensed Internal Code banner, the copyright boilerplate, the EBCDIC-to-ASCII translation tables, and the <code>PGPM</code> link names. A search for the entire relevant vocabulary — <code>POWER</code>, <code>FAN</code>, <code>THERMAL</code>, <code>SPCN</code>, <code>VPD</code>, <code>PASSWORD</code>, <code>SECUR</code>, <code>SERIAL</code> and more, in both EBCDIC and ASCII, over every byte — returns nothing in any service-processor module. The same vocabulary ''is'' present elsewhere in the container, but only inside SLIC payloads.

So the honest position is that the functional surface visible here is nine supervisor call numbers into firmware nobody has. What the service processor actually does is implemented on the other side of that boundary.

One bound on that negative: readable code averages about 46 % of 1 KiB blocks across these images, and one 119 KiB payload is entirely opaque. The supported statement is that nothing is visible in the readable portion, not that nothing exists.

=== Directory extents ===
Seven payloads are not data but further runs of 32-byte LID records, largely duplicating entries from the root directory byte for byte. The two largest hold 294 and 133 records. They appear to be indexes rather than nested containers, and a tool walking this file should recognise them so as not to mistake an index for a firmware image. A payload whose first few records parse as plausible LID records, with identifiers matching known LIDs, is an extent.

== Compression ==
341 of the 632 payloads are flagged compressed. The codec is the LZW variant used throughout SLIC and is described at [[Data Structures:LID#The compressed flag]]. It has not been needed to read the service processor firmware, which is stored plain, but it stands between the reader and roughly half the file.

== Tooling ==
No IBM-supplied tool for reading this file outside the machine is known. A parser must, at minimum:
# check the <code>IMD1</code> magic at offset 0;
# read the banner offset from <code>+0x08</code> and '''derive''' the directory position from it, rather than assuming a constant;
# read 32-byte records until an identifier of <code>0xC5D5C440</code> or zero;
# place the payload area at the next block boundary after that terminator;
# lay payloads out sequentially in directory order.

Step 2 is the one that catches people. An implementation that hardcodes the V4R4 directory offset of <code>0x420</code> does not fail loudly on a V7R2 container — it reports zero records and a nonsensical payload start. Deriving the offsets costs nothing and works on both.

== Across releases ==
Comparing a V4R4 image with a V7R2 one shows how much of this is format and how much was accident of a single sample.

{|class="wikitable"
!
!V4R4
!V7R2
|-
|Records
|632
|961
|-
|Compressed
|341
|557
|-
|Payload
|77.5 MiB
|288.7 MiB
|-
|<code>PGPM</code> module headers
|119
|104
|}

The record format, the <code>PGPM</code> module header and its field offsets, the payload tiling rule and the <code>END </code> terminator are all unchanged. What varies is the header offsets, which the header itself declares.

The service processor module namespace is also strikingly stable. Fourteen <code>SP</code> module names are defined in both releases, and the pattern of numbered names being imported but never defined — the evidence that they live in flash on the card — reproduces exactly sixteen years apart. So does the supervisor call vocabulary, with V7R2 adding one new call number.

What did change is on the SLIC side, and it is what you would expect once the service processor and panel stop being discrete cards. The concrete hardware driver classes are simply gone in V7R2, while the message protocol and resource model that sat on top of them survive and grow. In their place, the panel and service processor objects are constructed from new ''virtual'' VPD providers. The interface is preserved and the implementation behind it is virtualised — which is why code written against the older message classes still reads as recognisable on a modern machine.

== Open questions ==
* The header field at <code>+0x0C</code>, which differs between samples (<code>00e00000</code> against <code>00100000</code>).
* The rest of the header between <code>+0x0C</code> and the banner.
* The meaning of most LID identifier families.
* Why some payloads carry the compressed flag yet begin with plainly readable 32-bit code.
* Whether the load-source LBAs in the offset field can be used to reconstruct the physical layout of the original installation medium.
* The <code>PGPM</code> identifier discrepancy described above.

== See also ==
* [[Data Structures:LID]]
* [[CISC AS/400 LIC Tapes]]
* [[Copying disks with Linux]]

== Weblinks ==
* [https://www.mcpressonline.com/ MC Press Online], which carries older documentation describing service processor microcode as being loaded from the load source

[[Category: System Internals]]