terrible programmers: my god, it's full of chars

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > terrible programmers: my god, it's full of chars

Sweevo: Nov 8, 2007; i sometimes throw cables away

i mean straight into the bin without spending 10+ years in the box of might-come-in-handy-someday first

im a fucking monster

i do all my programming in DOS using turbo c and djgpp. does that make me terrible?

# ¿ May 7, 2013 22:10

Adbot: ADBOT LOVES YOU

# ¿ Apr 27, 2024 18:08

Sweevo: Nov 8, 2007; i sometimes throw cables away

i mean straight into the bin without spending 10+ years in the box of might-come-in-handy-someday first

im a fucking monster

JawnV6 posted:

remember the days when cs programs were stuck on crusty ol' pascal when the industry was clearly standardizing on java

mine switched to pascal in 1998 because the modula-2 compiler they'd been using for years crashed on their new-fangled pentiums.

# ¿ Aug 3, 2016 14:10

Sweevo: Nov 8, 2007; i sometimes throw cables away

i mean straight into the bin without spending 10+ years in the box of might-come-in-handy-someday first

im a fucking monster

which open source licence pisses off RMS the most? whatever it is you should use that.

# ¿ Aug 6, 2016 11:02

Sweevo: Nov 8, 2007; i sometimes throw cables away

i mean straight into the bin without spending 10+ years in the box of might-come-in-handy-someday first

im a fucking monster

windows is the least worst operating system

# ¿ Aug 9, 2016 14:02

Sweevo: Nov 8, 2007; i sometimes throw cables away

i mean straight into the bin without spending 10+ years in the box of might-come-in-handy-someday first

im a fucking monster

Luigi Thirty posted:

someone posted a horror story about the SAS installer trying to install an X client on their z-series mainframe to run a graphical Java installer

quazi posted:

Everybody is familiar with the concept of a bloated installer. Stuff like iTunes, NVIDIA drivers, the whole OS.. and not just Windows -- Mac users are having to deal with this crap too. Everything is getting too fat, and it's not just the nerd siting in the chair.

The absolute last platform I expected to see a bloated installer was an IBM mainframe running z/OS. For those of you not familiar with it, this is a text-based world full of simple-looking stuff that performs insanely powerful tasks. The closest thing I can equate it to is Unix or DOS, and even then, that analogy breaks down within seconds.

Even though I've only been a system admin for four years, I still have experience with products like: IOF, CA Disk, TMON, MXG, Syncsort.. Due to the spartan interface on this platform, products don't install anything remotely looking like a whiz-bang feature. Most mainframe programmers pride themselves in writing software with as little overhead as possible. Most of the time, an installation routine involves a series of batch jobs where you edit some dataset names to point them in the right direction, run those jobs, edit a couple config files, and boom -- you've installed something!

For the longest time, the most complicated install procedure I encountered was to verify that a handle in CA Disk was configured to view dataset control blocks in such a way as to make the backup utility jobs not mark the 'last accessed' field in datasets they were looking at. Stuff like that can twist your brain into knots if you're not careful, but even then, configuring it was a matter of setting a parm and executing a job.

Most software weighs in between 10MB and 100MB, while CA Disk was around 600MB. (oooh! it nearly filled a 3490 tape!) But when you consider that it's a third-party replacement for a fundamental part of the OS, that's kinda expected.

Enter SAS, an 800-pound behemoth of statistical analysis software. We've got several departments who rely on this, and since I'm the junior sysadmin, it's naturally my job to make sure the software is kept up to date.

I log into the SAS website and find the latest installation file (Release 9.2). It's 8MB. I think, "that's not bad for something that does so much! This mainframe platform sure is efficient!"

I then follow the instructions and upload it to the Unix side of the system. (Background) All of the latest IBM mainframes are divided into two sections -- z/OS and Unix, where the Unix side is also known as OMVS (Open Systems). The OMVS side is more of a vestigial growth that hangs off z/OS, but the two sides have complete read-write access between eachother.

The next step in the process is a bit baffling. "Set up an X Window server on your workstation." It turns out that the installer is a panel-driven wizard, and now the mainframe, which up until this point has only dealt with a text interface, now has to drive a graphical interface. I can't help but wonder what the hell the installer could possibly be doing in the background that I couldn't do by hand, but I was curious to see this. (Also, it's the only method for installing the product.)

My supervisor hooks me up with an IBM-recommended X-server, and upon running the SAS installer and connecting it to my workstation, a little "Press 'Next' to continue the SAS installation process" window pops up on my machine! Sure as poo poo!

But as nice as that sounds, that's when everything starts going to hell. My mainframe user account spikes to 100% CPU usage and stays there as long as I have the X-server connected. This triggers a resource shortage, which triggers a red message on the master console, which leads to a phone call from the folks in the datacenter making GBS threads themselves asking me if they need to worry about this. The next big surprise is that this installer doesn't actually install the product, it's just a downloader. Remember when I said that we mainframe admins consider a 600MB installation a big thing? Well, the SAS Downloader pops up a message warning me that I don't have the space to download all 7.8GB of the product.

SEVEN POINT EIGHT GIGABYTES?! GREAT SCOTT

I feel the need to remind you that this is a product for a text-based interface. "What the hell?" doesn't even begin to describe what I'm thinking. First, what could possibly be in it? Second, our system cannot allocate an OMVS volume big enough to contain it, and I'm pretty sure a company with such a rich mainframe heritage as the SAS Institute would be well aware of this type of limitation. (OMVS volumes are actually z/OS datasets, and the largest dataset we can allocate is 10,000 cylinders*, which comes out to a little bit less than 7.8GB.)

_{*-- There are ways around this, but it's drat tricky once you've put the machine in production.}

I hop back on SAS's website and find a Windows version of that same downloader, along with instructions for downloading the data to my workstation and then uploading it back to the mainframe. Even though I don't have the space to upload it, I want to see what's in it.. And yes, I verified with SAS tech support that both the z/OS and Windows versions of the downloader get the exact same data.

I use WinDirStat to try to find out what is making this sucker so damned big.

- It has a tree with over 1500 subfolders.

By file type:
- There are over 500 JAR files (which it probably uses), and they weigh in at 1.8GB.
- There are nearly 100 ZIP files, and they're 1.6GB.
- Some "PAX" files.. 1.3GB.. (if they're what I think they are, they're kinda like zips)

But the next one is so funny it makes me cry inside:
- 191 EXE files, 853MB.

You know, "Windows executables".. Programs that run on Windows. Programs that have no business taking up precious space on a mainframe because z/OS considers them to be complete gibberish. The average mainframe is so big that it makes a Windows box look like a cell phone, and ours is no different. It needs Windows EXE files like a fish needs a bicycle. "What the gently caress is this poo poo doing here, SAS?!"

I check the folder tree, and there's 200MB of .Net redistributables and service packs, 220MB of ACE redistributables (in nine different languages!), 176MB of JET redist (in 20 languages), and over 1GB of products that can only be installed using their respective "setup.exe" files. It turns out that the SAS Download Manager grabs the installation data for every single platform for which SAS is available, and it doesn't give you the ability to 'uncheck' any of it. It's all 7.8GB or nothing.

I call SAS tech support to see if there's any way to get a smaller installation package (similar to the previous version, which was about one-tenth the size)..
-- Their answer: "no."

-- Me: Can I just delete all of the EXE files, and remove the folders that are obviously installing stuff that is foreign to the mainframe?

-- Them: "Uhh.. that's a bad idea. This installer is Java based, and Java is cross-platform and it might need to access some of that data and possibly execute some of those exe's in the background."

Let's just say the conversation fizzled from there and I gave up.

gently caress it, we're sticking with SAS Release 8.2 until the end of time.

# ¿ Aug 10, 2016 21:14

Sweevo: Nov 8, 2007; i sometimes throw cables away

i mean straight into the bin without spending 10+ years in the box of might-come-in-handy-someday first

im a fucking monster

Luigi Thirty posted:

huh. i found the old 486SLC 25MHz laptop that my cousin gave me when he graduated college. i tried to run POLYGON.EXE on it and it just crashes. could be because i'm running it on a 486 with no FPU, it has 3MB of RAM, or something else! oh well

you're not compiling it with 586 instructions are you?

# ¿ Aug 12, 2016 10:41

Sweevo: Nov 8, 2007; i sometimes throw cables away

i mean straight into the bin without spending 10+ years in the box of might-come-in-handy-someday first

im a fucking monster

Luigi Thirty posted:

i downloaded that 68k emulator/debugger easy68k to play with. it includes all kinds of simulated peripherals, serial connection, file i/o, even TCP and UDP networking. i decided i wanted to try clearing the 7-segment LEDs
code:
START:
    move.b #8, d0 ;clear 8-character LED
    move.l #$00E00000, a0
    
CLEARLCD:
    move.w #$0000, (a0)+ ;gently caress poo poo PISS	
    subq #1, d0
    cmp #0, d0
    bne CLEARLCD
this instruction set is magic holy poo poo autoincrementing memory addresses

subq already sets the flags if you're operating on a data register, so no need for the cmp #0. you could also remove both subq+cmp and replace the branch with dbne d0,CLEARLCD.

auto inc/dec owns. that's why i like the 6809

Sweevo fucked around with this message at 16:09 on Aug 13, 2016

# ¿ Aug 13, 2016 15:56

Sweevo: Nov 8, 2007; i sometimes throw cables away

i mean straight into the bin without spending 10+ years in the box of might-come-in-handy-someday first

im a fucking monster

Luigi Thirty posted:

took me a little while to figure out how to read a 32-bit little endian number (all FAT12 data is little endian) into a 32-bit big endian register lol

code:

ror.w #8,d0
swap d0
ror.w #8,d0

# ¿ Aug 14, 2016 11:17

Sweevo: Nov 8, 2007; i sometimes throw cables away

i mean straight into the bin without spending 10+ years in the box of might-come-in-handy-someday first

im a fucking monster

for some reason that xor thing used to show up in every lovely online pascal tutorial back in the 90s, and pascal programmers used to go :aaaaa:

over it.

the only time it's actually useful if if you're targeting some 8-bit micro with only a few dozen bytes of ram and you have to make every one count.

# ¿ Aug 18, 2016 15:45

Sweevo: Nov 8, 2007; i sometimes throw cables away

i mean straight into the bin without spending 10+ years in the box of might-come-in-handy-someday first

im a fucking monster

Bloody posted:

the only hypothetical ive come up with is if:
* you're on a platform without shadow registers/banked registers
* your register usage is highly optimized
* you have extremely sensitive hand-coded interrupts that might interrupt this function
* this one instance will cause you to use one more register than anywhere else in interruptable code
* your isr needs all of the registers
now your isr can save one fewer register on the stack at entry and restore one fewer at exit

and, somewhere out there, there's a code base with exactly this for some reason

* and you're using an architecture that lacks a dedicated register<->register swap/exchange instruction

# ¿ Aug 18, 2016 16:39

Sweevo: Nov 8, 2007; i sometimes throw cables away

i mean straight into the bin without spending 10+ years in the box of might-come-in-handy-someday first

im a fucking monster

Luigi Thirty posted:

if only it were 1986 and I could make lots of money off my autism for 68000s and 6502s

you never know. about 3 years ago we had to hire a contractor who knew z8000 assembly.

# ¿ Aug 21, 2016 11:33

Sweevo: Nov 8, 2007; i sometimes throw cables away

i mean straight into the bin without spending 10+ years in the box of might-come-in-handy-someday first

im a fucking monster

Luigi Thirty posted:

It turns out drawing a horizontal line of pixels in a 1bpp graphics mode is faster if you do it in groups of 1 byte and then figure out how many are left over at the end instead of doing it one pixel at a time

do you have to break it down to bytes? couldn't you write 32 bits in one operation and then do any cleanup at the end if the start/end points aren't on 4-byte boundaries?

# ¿ Aug 31, 2016 19:19

Sweevo: Nov 8, 2007; i sometimes throw cables away

i mean straight into the bin without spending 10+ years in the box of might-come-in-handy-someday first

im a fucking monster

Luigi Thirty posted:

I'd buy an Amiga but there's just so goddamn many models and upgrade paths and the technical wizardry is all written for PAL machines anyway so I'd rather use WinUAE

back in the day the only models publishers cared about were the 500 and 1200, so everything was designed to run on those and if it worked on any other models then that was a coincidence (although compatibility between models was very good).

a stock 1200 or a 500 with a 1mb upgrade will run 95% of games. demoscene stuff quickly went 1200-only, and most things written after about 1995 need a RAM upgrade as well, but ram upgrades for the 1200 fetch silly money and are not worth it when you can just emulate it.

# ¿ Sep 26, 2016 13:19

Sweevo: Nov 8, 2007; i sometimes throw cables away

i mean straight into the bin without spending 10+ years in the box of might-come-in-handy-someday first

im a fucking monster

Luigi Thirty posted:

I should probably do this junk in a system-friendly way instead of loving with hardware registers directly but for some reason Amiga devs are allergic to operating system APIs

yeah its weird like that. you have to do a lot of things semi-manually compared to how they'd work on a modern OS, but i guess the tradeoff is that you can do exactly what you need and nothing more, instead of calling high-level API functions that probably do a ton of unnecessary housekeeping behind the scenes.

the os can do virtual screens (i think they were actually referred to as "screens" in the documentation), so the os-friendly thing to do would probably be to create a new screen and a bitmap for it, and then draw on the bitmap. then you can bring your screen to the front, or drag the os screen down by the menu bar to show the screen behind it or whatever

# ¿ Oct 31, 2016 23:23

Sweevo: Nov 8, 2007; i sometimes throw cables away

i mean straight into the bin without spending 10+ years in the box of might-come-in-handy-someday first

im a fucking monster

Luigi Thirty posted:

well i haven't figured out the amiga's built-in blitter-based animation system yet but i can draw a bunch of bitmaps in succession so my amiga can play the WHOLE GIF

# ¿ Nov 6, 2016 12:47

Sweevo: Nov 8, 2007; i sometimes throw cables away

i mean straight into the bin without spending 10+ years in the box of might-come-in-handy-someday first

im a fucking monster

eschaton posted:

why not use E? er, Amiga E?

its author has this to say about it:

i wrote a few small things in E about 20 years ago. from what i remember its basically just pascal, but with more C-like syntax and a thin wrapper over some of the basic OS functions

# ¿ Nov 15, 2016 15:41

Sweevo: Nov 8, 2007; i sometimes throw cables away

i mean straight into the bin without spending 10+ years in the box of might-come-in-handy-someday first

im a fucking monster

Luigi Thirty posted:

the latest emacs port to AmigaOS is 20.3 from 1999, probably still usable and better than SAS/C's editor

the OS comes with microemacs but I haven't tried it

give FrexxEd or EdWord a go

# ¿ Nov 17, 2016 23:00

Sweevo: Nov 8, 2007; i sometimes throw cables away

i mean straight into the bin without spending 10+ years in the box of might-come-in-handy-someday first

im a fucking monster

is w3c still whacking off over the semantic web and other poo poo that will never happen?

# ¿ Dec 23, 2016 00:43

Sweevo: Nov 8, 2007; i sometimes throw cables away

i mean straight into the bin without spending 10+ years in the box of might-come-in-handy-someday first

im a fucking monster

9-Volt Assault posted:

Put out job ad, get 200 applications, you pick the best one and the other 199 are blocked forever from applying in the future. It sounds dumb enough that its probably true.

recruiter puts out ad, recruiter gets 200 applications, recruiter runs 200 applications through a bunch of macros that eliminates 190 applications for completely arbitrary reasons, employer is given 10 and picks 5 to interview, recruiter is given a sack of cash, recruiter instantly forgets the 195 rejected applicants who could apply every day for a year and the recruiter still wouldn't notice.

# ¿ Dec 23, 2016 17:05

Sweevo: Nov 8, 2007; i sometimes throw cables away

i mean straight into the bin without spending 10+ years in the box of might-come-in-handy-someday first

im a fucking monster

Sapozhnik posted:

Lisp was the first plang

i dunno, plangs are very occasionally used to write something useful

# ¿ Jan 11, 2017 16:09

Sweevo: Nov 8, 2007; i sometimes throw cables away

i mean straight into the bin without spending 10+ years in the box of might-come-in-handy-someday first

im a fucking monster

GameCube posted:

i had to get shift-jis working on an old label printer here that hooked up by serial port. it turned out that you had to send the hex codes as ascii characters

like, for example, if you wanted to print 軌, that maps to 0x8b4f in shift-jis, so you would actually have to send the string '8b4f' in ascii, doubling the data size and at least quadrupling the dev time required to figure out that's what the lovely instructions were telling you to do

there is a special place in hell for the people who write label printer firmware. you get all the downsides of dealing with printers, plus all the downsides of industrial hardware, plus all the downsides of weird proprietary comms protocols

# ¿ Feb 1, 2017 21:08

Sweevo: Nov 8, 2007; i sometimes throw cables away

i mean straight into the bin without spending 10+ years in the box of might-come-in-handy-someday first

im a fucking monster

carry on then posted:

here's a video from 1973 about a computer room: https://www.youtube.com/watch?v=HMYiktO0D64

lol at part 2: "can't be bothered to type your own punch cards? submit your code to the typing pool and let a woman do it for you"

# ¿ Mar 7, 2017 21:50

Sweevo: Nov 8, 2007; i sometimes throw cables away

i mean straight into the bin without spending 10+ years in the box of might-come-in-handy-someday first

im a fucking monster

Rectus posted:

get the math coprocessor for it

probably not worth it. floating point was still poo poo slow with a 387. it was slightly slower with a 486DX, and didn't get fast until the pentium

# ¿ Mar 13, 2017 00:58

Sweevo: Nov 8, 2007; i sometimes throw cables away

i mean straight into the bin without spending 10+ years in the box of might-come-in-handy-someday first

im a fucking monster

Luigi Thirty posted:

every 90s operating system needs a clone of the nextstep dock

the texture is bad because it's a 256-color image and the desktop is set to 16 colors because OCS

ditch the crappy dock and use ToolsDaemon to put all your most-used software in a menu.

# ¿ Mar 25, 2017 20:05

Sweevo: Nov 8, 2007; i sometimes throw cables away

i mean straight into the bin without spending 10+ years in the box of might-come-in-handy-someday first

im a fucking monster

Wheany posted:

i'll see your custom laggy scrolling code and raise you custom laggy scrolling code with a weird jump when the header is almost out of view and gets replaced with a fixed narrowed header

infinite scrolling that lets you see two screens worth and then throws up a translucent overlay demanding you register

# ¿ Apr 4, 2017 13:41

Sweevo: Nov 8, 2007; i sometimes throw cables away

i mean straight into the bin without spending 10+ years in the box of might-come-in-handy-someday first

im a fucking monster

Jabor posted:

the device actually triggering the interrupt is supposed to write a particular value. so you can set up an interrupt table and then jump to the handler corresponding to that peripheral.

are you using a particular machine that has badly-behaved peripherals?

that mechanism only works if you use 100% compatible peripherals like the zilog PIO/SIO/etc instead of the much more common intel-compatible chips. letting the data bus float and using a 256 byte table to trap every possible value was a common trick on most z80 computers. IM0 was rarely used because it also needs hardware support, and IM1 usually jumped somewhere in ROM meaning the programmer couldn't change it to point to their own routine. So IM2 with the table trick was the only option available.

Sweevo fucked around with this message at 11:39 on Apr 9, 2017

# ¿ Apr 9, 2017 11:00

Sweevo: Nov 8, 2007; i sometimes throw cables away

i mean straight into the bin without spending 10+ years in the box of might-come-in-handy-someday first

im a fucking monster

because CS is a technical degree that focuses more on things like information theory than on the day to day minutiae

it's like complaining that someone with a degree in pure mathematics isn't a very good accountant

# ¿ Apr 20, 2017 14:46

Sweevo: Nov 8, 2007; i sometimes throw cables away

i mean straight into the bin without spending 10+ years in the box of might-come-in-handy-someday first

im a fucking monster

ultravoices posted:

did pascal just die because of that considered harmful essay, because it was the language for a decade plus

iirc it was only really ubiquitous in the PC world, and slanted very much towards the hobbyist scene. if you wanted to write a rotating 3d fire cube for VGA mode 13 then pascal was everywhere. C was already the de-facto standard for everything else

# ¿ May 8, 2017 15:33

Sweevo: Nov 8, 2007; i sometimes throw cables away

i mean straight into the bin without spending 10+ years in the box of might-come-in-handy-someday first

im a fucking monster

every few years i think mainframes might be interesting to learn about and every time i get five minutes in before it turns into a hall of mirrors nightmare of impenetrable three-letter acronyms and weird non-standard terminology

# ¿ Jun 8, 2017 18:13

Sweevo: Nov 8, 2007; i sometimes throw cables away

i mean straight into the bin without spending 10+ years in the box of might-come-in-handy-someday first

im a fucking monster

carry on then posted:

actually i think you'll find that s360 family computers have been around for far longer than micros and therefore it is the microcomputers that are nons-*chokes on own grey beard*

we have these things called "files" now grandpa, i have no idea what a "dataset" is or why i have to CMK into the JEP to mount one before I can TBS it over to the PVK

# ¿ Jun 8, 2017 21:23

Sweevo: Nov 8, 2007; i sometimes throw cables away

i mean straight into the bin without spending 10+ years in the box of might-come-in-handy-someday first

im a fucking monster

anthonypants posted:

no, remind me

quazi posted:

Everybody is familiar with the concept of a bloated installer. Stuff like iTunes, NVIDIA drivers, the whole OS.. and not just Windows -- Mac users are having to deal with this crap too. Everything is getting too fat, and it's not just the nerd siting in the chair.

The absolute last platform I expected to see a bloated installer was an IBM mainframe running z/OS. For those of you not familiar with it, this is a text-based world full of simple-looking stuff that performs insanely powerful tasks. The closest thing I can equate it to is Unix or DOS, and even then, that analogy breaks down within seconds.

Even though I've only been a system admin for four years, I still have experience with products like: IOF, CA Disk, TMON, MXG, Syncsort.. Due to the spartan interface on this platform, products don't install anything remotely looking like a whiz-bang feature. Most mainframe programmers pride themselves in writing software with as little overhead as possible. Most of the time, an installation routine involves a series of batch jobs where you edit some dataset names to point them in the right direction, run those jobs, edit a couple config files, and boom -- you've installed something!

For the longest time, the most complicated install procedure I encountered was to verify that a handle in CA Disk was configured to view dataset control blocks in such a way as to make the backup utility jobs not mark the 'last accessed' field in datasets they were looking at. Stuff like that can twist your brain into knots if you're not careful, but even then, configuring it was a matter of setting a parm and executing a job.

Most software weighs in between 10MB and 100MB, while CA Disk was around 600MB. (oooh! it nearly filled a 3490 tape!) But when you consider that it's a third-party replacement for a fundamental part of the OS, that's kinda expected.

Enter SAS, an 800-pound behemoth of statistical analysis software. We've got several departments who rely on this, and since I'm the junior sysadmin, it's naturally my job to make sure the software is kept up to date.

I log into the SAS website and find the latest installation file (Release 9.2). It's 8MB. I think, "that's not bad for something that does so much! This mainframe platform sure is efficient!"

I then follow the instructions and upload it to the Unix side of the system. (Background) All of the latest IBM mainframes are divided into two sections -- z/OS and Unix, where the Unix side is also known as OMVS (Open Systems). The OMVS side is more of a vestigial growth that hangs off z/OS, but the two sides have complete read-write access between eachother.

The next step in the process is a bit baffling. "Set up an X Window server on your workstation." It turns out that the installer is a panel-driven wizard, and now the mainframe, which up until this point has only dealt with a text interface, now has to drive a graphical interface. I can't help but wonder what the hell the installer could possibly be doing in the background that I couldn't do by hand, but I was curious to see this. (Also, it's the only method for installing the product.)

My supervisor hooks me up with an IBM-recommended X-server, and upon running the SAS installer and connecting it to my workstation, a little "Press 'Next' to continue the SAS installation process" window pops up on my machine! Sure as poo poo!

But as nice as that sounds, that's when everything starts going to hell. My mainframe user account spikes to 100% CPU usage and stays there as long as I have the X-server connected. This triggers a resource shortage, which triggers a red message on the master console, which leads to a phone call from the folks in the datacenter making GBS threads themselves asking me if they need to worry about this. The next big surprise is that this installer doesn't actually install the product, it's just a downloader. Remember when I said that we mainframe admins consider a 600MB installation a big thing? Well, the SAS Downloader pops up a message warning me that I don't have the space to download all 7.8GB of the product.

SEVEN POINT EIGHT GIGABYTES?! GREAT SCOTT

I feel the need to remind you that this is a product for a text-based interface. "What the hell?" doesn't even begin to describe what I'm thinking. First, what could possibly be in it? Second, our system cannot allocate an OMVS volume big enough to contain it, and I'm pretty sure a company with such a rich mainframe heritage as the SAS Institute would be well aware of this type of limitation. (OMVS volumes are actually z/OS datasets, and the largest dataset we can allocate is 10,000 cylinders*, which comes out to a little bit less than 7.8GB.)

*-- There are ways around this, but it's drat tricky once you've put the machine in production.

I hop back on SAS's website and find a Windows version of that same downloader, along with instructions for downloading the data to my workstation and then uploading it back to the mainframe. Even though I don't have the space to upload it, I want to see what's in it.. And yes, I verified with SAS tech support that both the z/OS and Windows versions of the downloader get the exact same data.

I use WinDirStat to try to find out what is making this sucker so damned big.

- It has a tree with over 1500 subfolders.

By file type:
- There are over 500 JAR files (which it probably uses), and they weigh in at 1.8GB.
- There are nearly 100 ZIP files, and they're 1.6GB.
- Some "PAX" files.. 1.3GB.. (if they're what I think they are, they're kinda like zips)

But the next one is so funny it makes me cry inside:
- 191 EXE files, 853MB.

You know, "Windows executables".. Programs that run on Windows. Programs that have no business taking up precious space on a mainframe because z/OS considers them to be complete gibberish. The average mainframe is so big that it makes a Windows box look like a cell phone, and ours is no different. It needs Windows EXE files like a fish needs a bicycle. "What the gently caress is this poo poo doing here, SAS?!"

I check the folder tree, and there's 200MB of .Net redistributables and service packs, 220MB of ACE redistributables (in nine different languages!), 176MB of JET redist (in 20 languages), and over 1GB of products that can only be installed using their respective "setup.exe" files. It turns out that the SAS Download Manager grabs the installation data for every single platform for which SAS is available, and it doesn't give you the ability to 'uncheck' any of it. It's all 7.8GB or nothing.

I call SAS tech support to see if there's any way to get a smaller installation package (similar to the previous version, which was about one-tenth the size)..
-- Their answer: "no."

-- Me: Can I just delete all of the EXE files, and remove the folders that are obviously installing stuff that is foreign to the mainframe?

-- Them: "Uhh.. that's a bad idea. This installer is Java based, and Java is cross-platform and it might need to access some of that data and possibly execute some of those exe's in the background."

Let's just say the conversation fizzled from there and I gave up.

gently caress it, we're sticking with SAS Release 8.2 until the end of time.

# ¿ Jul 16, 2017 23:01

Sweevo: Nov 8, 2007; i sometimes throw cables away

i mean straight into the bin without spending 10+ years in the box of might-come-in-handy-someday first

im a fucking monster

telling Jeff Minter that his games suck is funny because he's incapable of taking criticism and will still be whining about it a decade later

# ¿ Sep 4, 2017 17:16

Sweevo: Nov 8, 2007; i sometimes throw cables away

i mean straight into the bin without spending 10+ years in the box of might-come-in-handy-someday first

im a fucking monster

Luigi Thirty posted:

https://twitter.com/LuigiThirty/status/907645555798618113

workaround: don't use jump instructions. this means virtually all code will not run correctly from external memory

someone looked at this poo poo and said "who cares, ship it." :psyduck:

# ¿ Sep 14, 2017 14:24

Sweevo: Nov 8, 2007; i sometimes throw cables away

i mean straight into the bin without spending 10+ years in the box of might-come-in-handy-someday first

im a fucking monster

Luigi Thirty posted:

also according to the DSP, the absolute value of signed zero ($80000000) is signed zero ($80000000)

I have no idea if that�s "right� or not

errata: accidentally implemented a hardware random number generator instead of a processor core
workaround: :flip:

# ¿ Sep 15, 2017 21:06

Sweevo: Nov 8, 2007; i sometimes throw cables away

i mean straight into the bin without spending 10+ years in the box of might-come-in-handy-someday first

im a fucking monster

Luigi Thirty posted:

okay Jaguar, now that I know translation and scale matrix multiplication works, let's try rotation. rotate this square 45 degrees on the Z axis

no. that is completely wrong.

maybe the code is right, but the jaguar does it wrong because of a hardware bug...

# ¿ Sep 21, 2017 12:05

Adbot: ADBOT LOVES YOU

# ¿ Apr 27, 2024 18:08

Sweevo: Nov 8, 2007; i sometimes throw cables away

i mean straight into the bin without spending 10+ years in the box of might-come-in-handy-someday first

im a fucking monster

lowtax is going to spend a week changing the fonts then claim the new look is xenforo 2.0 before disappearing for another 18 months.

# ¿ Oct 2, 2017 13:34

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > terrible programmers: my god, it's full of chars