TL;DR: No.
/360 code was usually way more compact for the same task than 1401 code. Partly due to shorter instructions (2..6 Bytes vs 1..8 Char
(*1)), partly due to a more capable ISA (use of registers, binary instead of BCD addressing, etc.).
Data may need a little more space due to alignment of integers - if used. The 1401 is a BCD-only machine with 1 digit per character, while the /360 stores two per byte (*2), thus up to halving the data storage needed for close (*3) converted 1401 programs as well.
In general such programs tended to use 5-20% less overall space (*4).
The Post
At best one could state that the the post in question is a rant based on vague memory, comparing apples and oranges without providing any information that could be used to validate the claims made.
To start one might read (and cite) the whole post made by Mr. Espen:
A 30 with 8K? What good would that be? A minimum DOS Sysgen would use ALL of that, more likely it would gen at around 10-12K.
As those systems came out, there was some confusion. A shop I worked in was running all their apps on 2 16K 14xx's. The 30 showed up with 32K. It' didn't take long to realize that wasn't going to cut it. 32K was a miniumum. If you wanted to run HLL compilers, you'd be better off with 64K. If you wanted to run more than one job at a time, 64K was the minimum. In a few years, spoolers became common. Even one job at a time required 64K.
I told an IBM salesman once that IBM had so bollixed up the architecture that our application programs were easily twice as large as they were on the 14xx. He checked with his technical people and had to concede the point.
And maybe as well his follow up comments. Likewise reading related replies would have shown all claims being debunked, or at least put into perspective.
But let's look at the claims:
Memory sizes
He seems to compare a top-end 1401 with maxed-out RAM of 16 kChar (*5) to a mid sized Model 30 which itself was the smallest Model to run DOS. That's a bit like comparing a fully fitted 24 KiB VIC-20 with a 48 KiB IBM-PC. Not really useful to start with, as the VIC does not need to load any DOS, while the PC will already fill half the memory with it (*6).
Same with the 32 KiB Model 30 - by using DOS, almost half is already used by DOS.
Machines
Well, if it was a 1401 at all, as he only states 14xx. A 1401 had a 1..8 character instruction size, while a 1440 used up to 12 per instruction (*7). So, which was it?
Also, the 1401 is a 1959 design, while the /360 is 1965 - 6 years that made a HUGE difference. The 32 KiB E30 is the direct replacement for a maxed 1401 with 16 kChar.
It's a bit like buying a modern PC to run DOS. The modern machine comes with more resources, but one would need them as well to do the old stuff. Even ignoring Windows (or Linux), a DOS emulator alone takes today more than a basic 1982 PC could ever offer - the rather simple DOSbox comes as a 3.5 MiB sized EXE file. Of course, it does a lot more than just swapping opcodes...
Long Story Short: Every generation gets bigger for the same task, but that's not due to being wasteful.
Compilers
With the top-end 1401 configuration it's easy to run any compiler made for that machine - as none could have been written using more. For the /360, a 32 Ki Machine was about the base configuration to run DOS and a compiler. Same way as for the 1401, which would be delivered with as little as 1400 Char. But to run any useful compiler (Basic RPG or COBOL), 4000 Char would be needed, while full RPG and FORTRAN needed at least 8000 Char. Main difference to the /360 is that they did run on bare metal.
Long story short: Comparing different machines by numbers does not work without exact reasoning. Even less with different software generation.
OS or Not OS, That's A Question
The post makes it quite obvious that the shop in question did run its /360 machines under DOS. By deciding to do so, the minimum size was already 16 KiB - or as here seen 32 if one wanted to host useful applications. A typical DOS would need about 10-12 KiB for the OS (as mentioned), leaving only 20 available for user programs.
But there were different OS environments available - starting with the BPS - Basic Programming Support that did not require any hardware beside a punch card reader over disk-based BOS and tape-based TOS. BPS provided many tools and compilers out of the (literal punch card) box.
The mentioned SPOOL as being a later addition is a great hint that the shop in which Mr. Espen worked never bothered to go below DOS, as BPS, BOS and TOS already provided SPOOL early on (*8). I remember packages that allowed semi-automatically (*9) converted 1401 programs under BPS.
Long story short: Mr. Espen's experience seems to be based on using a highly-evolved OS in addition to whatever application software, but not considering the cost that comes with doing so.
Application Part 1: What is an A. ?
That mentioning of Sysgen (*10) right at the start is as great point here . especially when considering that it is still that present in Mr. Espen's memory. People end to remember things done often better.
Back then it was common practice to not Sysgen a single DOS according to the hardware configuration, but application specific configurations. If a program only needed two tape drives out of the 6 installed, a DOS would be loaded that included only those two drives were Sysgen-ed, saving 4 tape buffers and 2/3rd of he management structures. Same for disk drives, printers and any other I/O and service needed - or better not needed.
One might compare it to the way Apple II program disks were usually bootable, loading their own DOS, sometimes with modifications or specific extensions. Or the way early 1990s PCs had complex CONFIG.SYS / AUTOEXEC.BAT structures to allow booting specific to certain applications. All with the goal of loading only the needed drivers and max out memory.
Further it was quite common in early /360 times to additionally directly patch DOS to fit an application's needs (*11). For example the startup part of a program would simply put some data areas where the DOS loader code was - come on, who needs a loader after being loaded? Same way OS subroutines that happened to do exactly what one needed were directly called, even if it saved only 3-4 instructions.
Of course DOS needed to be loaded afterwards. A little cost to be paid compared to several hundred bytes of additional usable memory!
Long story short: Back in early /360 days the distinction between OS and application was often not existent at all - especially from the viewpoint of an operator who had to load both in tandem.
Application Part 2: Was it Ported At All?
Besides the definition of what an application is, simply stating about 1401 applications vs. 'the same' on /360 isn't as clear as it might seem.
Was that application
- fully ported to /360 environment,
- semi automatic ported or
- run in emulation mode?
Only the first one gets the benefit of greatly reduced code size. The second may or may not get smaller, depending on what functionality is needed to translate between 1401 access logic and /360 OS.
The last one will never shrink but always grow as it needs emulation support as well as translation layers. Even more if that emulation is to reassemble the existing 16,000 Char 1401 mentioned in that post.
1401 software was almost entirely Assembler (*12). FORTRAN was available since 1960, but had a huge block of p-code interpreter and not really popular on a business machine like the 1401, while COBOL was just recently invented (1960) and ported to the 1401, thus had no big impact at the time the /360 took over.
The standard way to run 1401 programs on a /360 was to use machine emulation - which the Model 30 CPU supported at the microcode level. Any machine emulation another needs more resources than the one being emulated - at least if it should perform somewhat comparably. This is especially true for memory.
Long Story Short: it's safe to assume these programs did run in emulation mode, thus by nature needing more space.
32 KiB Is 16 KiChar
The 32 KiB Model E30 was the lowest one able to fully emulate a 1401 (*13) as the microcode emulator needed the 1401 environment at absolute address (*14) x'4000' to x'7F9E' - essentially the second 16 KiB block in address space. In turn, the lower half was barely enough to fit DOS and the DOS based emulator runtime.
A big consideration is of course the price - or in case of IBM in the 1960s, the monthly rental. The 1401 with (8 kChar) was set at 3000 USD which was about the same price point the Model 30 pitched at. It was the choice for anyone having a 1401 and wanting to go into the /360 world - or just expanding memory without paying more.
Long Story Short: The E30 is what a computing center would order after 1965 to directly replace a 1401.
It's the Numbers, Stupid!
This goes with the second to last section, but I think it is too fundamental not to underline it once more:
- To emulate a machine with 16 KiB of memory, more than 16 KiB are needed.
and
- The E30 is the direct 1:1 next-generation replacement for the 1401.
That's it. To emulate jobs on a 16 KiB 1401, it needs a /360-30 of 32 KiB.
Question Parts:
Did the IBM 1401 really have twice the code density of the 360?
No. Going with the equivalence of character with byte, as Mr. Espen seems to do, a 1401 Instruction is 1..8 characters (*1), with an average close to 6, where the /360 uses 2, 4 or 6 bytes with an average below 4. So one-for-one there.
Or, perhaps more likely, were there some important workloads for which it did?
Can't think of any. As described, the additional memory was entirely needed for the additional functionality the /360 provided.
For native /360 each and every workload imagined would need lower or at most the same resources as on a 1401.
Or was it a matter of at least one of the 360 compilers, for at least some time, being not as good as its 1401 counterpart?
No. Compilers for the 1401 (past assembler that is) only become a thing rather shortly before the /360 came along and not much software had been written to use them. Especially not on a business machine like the 1401. The situation was of course different on the scientific end like 704(x)/709(x), where FORTRAN ruled.
*1 - The 1401 uses a variable length word, delimited by a word mark. For all practical purpose one can think of it as having BCD memory able to store characters as well.
*2 - That's what gave us today's 8-bit byte in the first place.
*3 - "Close" meaning programs converted to /360 without changing its data types or logic. E.g. still using BCD for all calculations.
*4 - A 1401 (BCD) ADD uses 7 char for the instruction, a /360 AP (Add Packed) 6 byte, a 5 digit number uses 5 char on 1401, but 3 bytes on /360.
*5 - For what it's worth we can use the same conflation of Char (*1) and Byte Mr. Espen uses throughout this when comparing 1401 and /360 memory footprint.
*6 - DOS 2.0 needs about 24 KiB, including the resident part of COMMAND.COM.
*7 - In part due to its increased address size of 80,000 characters, but also by enhanced instructions.
*8 - Having SPOOL on each machine was a main sales argument for the /360. It did greatly improve machine availability. Without it (on a 1401), a program had to wait for the printer. This blocked the machine way longer then needed - despite the CPU's slow operation. Shops with more than one machine often didn't let jobs print, instead writing tapes and dedicating one machine to printing those tapes. With SPOOL direct on each /360, programs could finish and let the next run, while the printer was still producing paper.
While real large computing centers still used a dedicated machine with SPOOL, operating many printers at once, mid-sized ones could now save the cost for a dedicated computer and small (like single computer) users now got way more production out of the same setup.
*9 - Converted much the same way as XLT86 was used to translate 8080 code to 8086. This worked surprisingly well, as the /360 was for most parts a superset of the 1401 due to combining multiple designs into one.
*10 - SYSGEN is the way to configure a DOS system. It compiles a DOS configuration from config files and stores it on disk to be loaded later on. With no tape configured, no tape routines were included. Likewise the number of tapes defined the number of buffers reserved and so on. All of course static.
*11 - I already mentioned the Apple II, didn't I?
*12 - Autocoder as they called it back then - the term Assembler became only widespread with the /360.
*13 - There was also the model 20 which could be turned into a 1401. It was meant as a 1:1 replacement for existing 1401. Mainly to save cost and unify landscape. It could not operate DOS in addition to the emulation, nor was it a full /360. Its ISA was a simplified 16-bit subset, so not able to run full DOS, even when equipped with 32 KiB.
*14 - Mentioning absolute might sound kind of redundant, as the -30 was a real-mode-only machine, but I guess it's helpful to underline that for today's readers.
