That makes my 11/21 not look so bad. Most of the ones that tripped me up were ones that they themselves said, “Yeah, we don’t get it either.”
A lot of these valid/invalid specs are illogical (why allow white space surrounding a segment of the address at all?) and don’t seem to serve any real purpose, especially considering that few servers will actually accept many of these “officially valid” forms. It goes to show just how much RFCs don’t tell you everything that matters.
I was highly amused by the inclusion of the fork bomb, though. Serious geek in-joke. They knew their audience.
Many of those early standards for mail addressing and headers was an attempt to construct a single common header standard that could be used to forward mail between all of these different networks.
Many of the requirements that don’t make any sense today made perfect sense in a world where mail server software developers (and the RFCs they were contributing to) were trying to bridge mail messages between all these otherwise incompatible networks.
Some of these “features” have since been deprecated, because the problem they were trying to solve no longer exists, but nothing ever completely goes away.
Much like @Incompatible, I once tried to write a regex to validate and parse email addresses. It was a hair-raising experience, and I have a lot of hair. So after the first two questions of the quiz, I NOPE’d out of there right quick.
It’s not just the servers. Many entities that require an email address to be used as a username choke on my valid email address. And then there’s one that requires an email address for any new transaction, and it rejects the email address that I have used multiple times before and that it has on file.
I bailed when I got to the first question where the “correct” answer was “valid” because it was permitted under an older RFC, even though it was changed to be invalid by a later, superseding RFC – the same RFC that the quiz claimed to be scoring against.
Quiz. Strictly according to the US constitution and its amendments, is it legal for state legislatures to appoint senators?
Me: That is illegal.
Quiz: Wrong, it was legal following the ratification of the constitution! It became illegal after the 17th amendment in 1913.
I didn’t like how, after I indicated “underscores” as valid, it explained those were actually spaces… how the heck was I supposed to do know that? And telling me they are spaces after I answer the question is just backward.
Pretty pointless quiz overall, though I guess it’s just for fun.
One I don’t see in the time list is the importance of getting date and time in the same call, or using a method where the underlying API is using one call. I see code that doesn’t do this; they’ll use one call to get a date (e.g. COBOL “accept from date”) and a second call to get the time. But what if the two calls are before and after midnight?
Is this an issue? Most operating systems these days (including everything Unix-derived and even classic Mac OS) don’t distinguish between date and time. The OS call returns a count of time-units since a well-known epoch.
The ISO C standard’s time() function returns an abstract time_t which on POSIX systems is a count of seconds since midnight January 1, 1970, UTC.
Although the C standard’s definition allows for other representations, it is required to be an arithmetic (integer or floating point) value that can be converted to/from real-world units using the standard library’s time functions (e.g. the localtime() and gmtime() calls).
Linux’s clock_gettime() function is similar, but with nanosecond resolution, in order to accommodate whatever accuracy/precision the computer is capable of. There are similar such functions in the C++ standard and I assume macOS and Windows APIs as well.
In other words, apps shouldn’t be getting date and time as separate calls. They should be getting a single value representing both. That value may be converted into whatever date/time units the application requires when presenting the value to the user.
REXX has separate functions for date() and time(); there is no date_time function. You need to know that to get a consistent date & time together, you must make both function calls in the same expression or clause.
Older versions of COBOL had separate verbs for returning date and time; I don’t think there was any way to get them together. Modern COBOL can, but you have to know to use the right syntax. I frequently see programs that don’t realize this.
Yuck. Sounds a like a gross deficiency in the language. I started skimming through a REXX reference, and it also appears that there is no way to generate a “UTC” time similar to C’s time_t, which means you end up forced to deal with nastiness like time zones, DST and leap years/seconds if you need accuracy.
When I used REXX (years ago, when I was developing OS/2 software), I primarily used it simply as an enhanced batch file language. For anything serious, where issues like this might arise, I always wrote a C program.
Do people actually write production software (not just helper scripts) in REXX?
I’m speaking as a z/OS developer with a lot of ISPF dialog development experience. I first started using TSO/E REXX [User’s Guide] [Reference] in 1990. I own Mike Cowlishaw’s REXX book – he invented the language for IBM.
As a replacement for the loathsome CLIST language, REXX is great. But it has a lot of limitations. I view it as a scripting language. Note that on z/OS, REXX is pervasive. A product that doesn’t support REXX isn’t work buying.
From what I see, the vast majority of commercial products that run on z/OS are not written in REXX. ISPF applications, where you’d think REXX would be best used, are usually C, assembler, or one of IBM’s internal PL/AS variants. (Only IBM gets to use PL/AS.) Some older applications may be PL/I. I know this because I have written a utility that scans the system load libraries and reports on the exact language and compiler version used by every program linked into every module. I haven’t seen a single instance of (compiled) REXX.
But what about customers of z/OS? In that case, they might decide to write large REXX applications. In the system I support, I’ve created a few small production steps in REXX, but only in cases where I needed the ability of REXX to interface with another product, or the REXX parsing capabilities were advantageous.
And, I support an IDE kind of system that I completely rewrote from CLIST to REXX. Its main exec is 4500 lines long. It is an ISPF application, but it isn’t 100% REXX; it uses assembler programs for things that can’t be done in REXX. (At the time the application was originally written there were limitations that would preclude using COBOL for such programs.)
That being said, I have run into monstrous REXX components of commercial applications. One is the IBM ISMF (Integrated Storage Management Facility) ISPF application. ISMF itself isn’t REXX, I think, but it has a batch reporting facility called NaviQuest which seems to be 100% REXX.
I think one reason why REXX isn’t used for production applications is that it is slow compared to the alternatives. It is especially slow at I/O. There’s no way I’d use it to read a file with millions of records – something that can be done quickly in other languages.
I need REXX code to generate the offset from local to UTC time, such as for generating email headers. I use this algorithm on z/OS, which always works.
/***********************************************************************
* time_zone *
* Calculate the local timezone offset from MVS system variables *
***********************************************************************/
time_zone: procedure
days_different = mvsvar('SYMDEF','LYR4') - mvsvar('SYMDEF','YR4')
if days_different = 0 then
days_different = mvsvar('SYMDEF','LJDAY') -,
mvsvar('SYMDEF','JDAY')
hours_different = mvsvar('SYMDEF','LHR') -,
mvsvar('SYMDEF','HR') + (24 * days_different)
min_different = right(abs(mvsvar('SYMDEF','MIN') -,
mvsvar('SYMDEF','LMIN')),2,'0')
sign = substr('+-',(hours_different < 0)+1,1)
return sign || right(abs(hours_different),2,'0')min_different
