<DocScrutinizer05>
prolly their own internal links between several subsystems also are via SSL, and now are down
norly has quit [Ping timeout: 260 seconds]
b1101 has quit [Quit: b1101]
<wpwrak>
maybe the upgrade of their RSCS infrastructure encountered some bump in the road :)
<DocScrutinizer05>
~wiki rscs
<infobot>
At http://en.wikipedia.org/wiki/RSCS (URL), Wikipedia explains: "'Remote Spooling Communications Subsystem' or 'RSCS' is a subsystem ("virtual machine" in VM terminology) of IBM's VM/370 operating system which accepts files transmitted to it from local or remote system and users and transmits them to destination local or remote users and systems. RSCS also transmits commands and messages among users and systems. RSCS is the software that powered the ...
<DocScrutinizer05>
this sounds about right, yes :-)
<DocScrutinizer05>
I guess it's actually some inter-system-communication (like RSCS) that barfs up and throws error
<DocScrutinizer05>
the web banking interface is not realtime connected to the system that does accounting
<DocScrutinizer05>
unclear if the transaction got accomplished nevertheless or not. They ask you to check your account in 4h and to report any transactions that got done twice or more, thanks to your refusal to ignore the "retry later" advice ;-P
<DocScrutinizer05>
that's often the problem with all those spools and buffers. You never know which job is lingering there, waiting for a din-Z42 printer or whatever sink to come up in a few years
<DocScrutinizer05>
or they spool everything to /dev/null and tell you "that worked *really* fine!"
<kerio>
just, you know
<kerio>
add a "spoold" to systemd
<kerio>
and then you can run spoolctl
<kerio>
to ask for the status of all the spools via dbus