Programming can get pretty tedious, so software developers often make up games and contests purely for amusement. A popular contest is to see who can code a solution to a simple problem in the least amount of code, often with extra points given for obscurity. My most recent bon-bon is the following snippet of code which is used to generate the page: << for (gnr in prc_genres) prc_menu(prc_genres[gnr]['title'], 'parms:genre:' + gnr); >>

In my heyday I was famous for embedding gobs of commentary in my source code so people who were learning my code wouldn't bother me with lots of dumb questions. I used to compete with myself to produce source with more lines of documentation than lines of code. In this Assembler-H example the ratio is a whopping 11.33. * DMIVSAM COPY VERSION OF 11/15/78 12:54:14 MACRO &LABEL DMIVSAM &OPTCD= OPTION CODE(S) .********************************************************************** .* * .* D M I V S A M S T R A T E G Y * .* * .* THIS MACRO (DMIVSAM) IS COPIED INTO (AND CALLED BY) * .* MOST IF NOT ALL DMI PROGRAMS THAT INTERFACE WITH VSAM. * .* AS OF 11/78 THESE CONSISTED OF DMIVSAM, DMIESDS, DMIKSDS * .* AND DMIRRDS. * .* * .* THESE PARAGRAPHS WILL ATTEMPT TO EXPLAIN THE * .* OVERALL STRATEGY WHICH HAS EVOLVED TO DEAL WITH THE MANY * .* AND VARIED QUANDARIES WE HAVE SOLVED IN GETTING VSAM * .* TO WORK WITH DMI/VS, AND HOW THIS MACRO CAME TO BE * .* WRITTEN. * .* * .* THE FIRST DECISION WE HAD TO MAKE (MOST OF THE TIME * .* 'WE' MEANS 'DEAN HANNOTTE') WAS JUST HOW TO CALL VSAM. * .* SINCE WE HAD TO BE REENTRANT, WE HAD TO EITHER MODIFY * .* GETMAINED COPIES OF CONTROL BLOCKS (WHICH WAS THE * .* TECHNIQUE WE WERE USING WITH QSAM), OR USE THE NEW GENCB/ * .* MODCB/TESTCB/SHOWCB MACROS. THE IOS UNIT (MOST OF THE TIME * .* 'THE IOS UNIT' MEANS 'STEVE GILDER') ADVISED US NOT TO * .* USE THE VAUNTED CONTROL BLOCK MANIPULATION MACROS SINCE * .* DSECTS FOR THE CONTROL BLOCKS WERE AVAILABLE (IF NOT * .* PUBLICIZED) AND THE RELATIVE CPU OVERHEAD OF THE TWO * .* TECHNIQUES WAS MAYBE FIFTY TO ONE. * .* * .* OUR INITIAL FORK-IN-THE-ROAD, THEREFORE, WAS TO * .* AMBLE DOWN DSECT HIGHWAY, BEARING WELL IN MIND THE * .* EXPOSURE AND RISK INVOLVED: IF IBM CHANGES THE CONTROL * .* BLOCK FORMATS WE'D BETTER FIND OUT ABOUT IT AND RE-ASSEMBLE * .* REAL QUICK (IT'LL NEVER HAPPEN, MIND YOU). * .* * .* IT WAS KNOWN AT THIS TIME THAT THIS TECHNIQUE MIGHT * .* NOT WORK UNDER CMS, SINCE CMS IS NOTORIOUSLY SLY ABOUT * .* 'SIMULATING' (IE IGNORING) MVS FUNCTIONS. SINCE THE CMS * .* MANUALS EXPLICITLY STATED THAT BAL PROGRAMS SIMPLY COULD * .* NOT ACCESS VSAM FILES UNDER CMS, WE DECIDED THAT OUR * .* INITIAL IMPLEMENTATION WOULD BE TARGETTED FOR MVS ONLY. * .* * .* WE GOT VSAM TO WORK UNDER MVS USING THE DSECTS, * .* AND FOUND THE APPROACH PERFECTLY ACCEPTABLE: NO BUGS HAVE * .* EVER BEEN FOUND (OR EVEN SUSPECTED), THE DSECTS HAVE NEVER * .* BEEN DELETED OR CHANGED, AND THE EFFICIENCY OF THE * .* INSTRUCTION PATHS WAS UNDENIABLY SUPERIOR TO THE * .* RECOMMENDED TECHNIQUE (ISN'T IT ALWAYS?). * .* * .* FINALLY, HOWEVER, IT CAME TIME TO BYTE THE BULLET * .* AND FACE THE DESIRABILITY OF GETTING VSAM TO WORK UNDER * .* CMS AS WELL. WE BRACED OURSELVES AND TRIED TO COMPREHEND * .* THE MAGNITUDE OF THE UNDERTAKING. IT DIDN'T WORK. * .* SO, RATHER THAN TRY TO UNDERSTAND WHAT WE HAD TO DO, * .* WE STARTED TO DO THINGS THAT WE HOPED WE'D BE ABLE TO * .* UNDERSTAND LATER. DON'T FEEL EMBARASSED IF YOU FIND * .* YOURSELF READING THIS PARAGRAPH TWICE. * .* * .* WE KNEW THAT CMS CALLS DOS SOFTWARE TO HANDLE VSAM * .* FILES. THEREFORE THE FILES HAVE TO BE IN DOS FORMAT, * .* AND ARE DEFINED BY THE DOS VERSION OF ACCESS METHOD * .* SERVICES. IT SEEMED REASONABLE TO ASSUME, THEREFORE, THAT * .* THE VSAM WE'D BE CALLING WOULD BE EXPECTING DOS PARAMETER * .* LISTS AND DOS CONTROL BLOCKS. * .* * .* ON THE OTHER HAND, WE WERE PERPLEXED BY THE FACT * .* THAT IBM EXPLICITLY SUPPORTS COBOL AND PL/I ACCESS TO * .* VSAM FILES UNDER CMS. THESE PROGRAMS WOULD NOT HAVE TO BE * .* COMPILED WITH ANY SPECIAL OPTIONS TO WORK, EITHER. * .* * .* WE FOUND COPIES OF THE DOS VSAM DSECTS AND CONFIRMED * .* THAT THE DOS PARAMETERS AND CONTROL BLOCKS WERE IN FACT * .* DIFFERENT FROM THEIR MVS BROTHERS AND SISTERS. * .* INTERESTINGLY ENOUGH, THOUGH, MOST OF THE FIELDS WHICH * .* SERVED THE SAME FUNCTIONS HAD IDENTICAL LABELS IN BOTH * .* DSECTS. THIS CONSISTENCY EXTENDED TO BIT EQUATES AS WELL. * .* * .* CLEARLY, IN ORDER FOR MVS COBOL AND PL/I PROGRAMS * .* TO WORK UNDER CMS, THEY MUST EITHER BE USING RATHER * .* EXOTIC TECHNIQUES (GENCB, MODCB, TESTCB AND SHOWCB * .* CERTAINLY FALL INTO THIS CATEGORY), OR ELSE SOME THIRD * .* PERSON WAS GETTING IN THERE AND MAGICALLY TRANSFORMING * .* THE PARAMETER LISTS AND CONTROL BLOCKS FROM MVS FORMAT * .* TO DOS FORMAT WITHOUT ANYBODY BEING THE WISER. * .* * .* AT FIRST WE THOUGHT THAT, KNOWING IBM, THEY PROBABLY * .* WERE USING THE CB MACROS IN THE COMPILED CODE AND DIDN'T * .* CARE ABOUT CPU OVERHEAD. SOMEBODY, I FORGET WHO, FOUND * .* OUT THOUGH THAT EITHER THEY NEVER DID OR THEY STOPPED * .* DOING IT. THEY WERE GENERATING ORDINARY STATIC CB'S, * .* JUST LIKE WE WERE. * .* * .* ABOUT THIS TIME, WE STARTED DIGGING INTO THE VM * .* SYSTEM-PROGRAMMER-TYPE PROGRAM LOGIC MANUALS, AND * .* FOUND OUT THAT, SURE ENOUGH, AN INTERFACE ROUTINE WAS * .* REFORMATTING THE ACB AND EXLST AT OPEN TIME, AND THE RPL * .* WHENEVER IT WAS USED FOR THE FIRST TIME. (ACB'S DON'T * .* POINT TO THE RPL'S, OTHERWISE THIS COULD ALL BE DONE AT * .* THE SAME TIME.) * .* * .* IT FINALLY OCCURRED TO US THAT OPERATING SYSTEM * .* TRANSPARENCY MIGHT BE MADE TO POP OUT OF THIS EQUATION * .* JUST BY ASSEMBLING TWO VERSION OF THE DMI PROGRAMS: * .* ONE USING THE MVS DSECTS, AND THE OTHER USING THE DOS * .* DSECTS. * .* * .* SEVERAL PROBLEMS REMAINED TO BE SOLVED, HOWEVER. * .* THE FIRST WAS THAT SEVERAL OF THE EQUATES FOR ERROR CODES * .* ENCOUNTERED IN MVS WERE NOT INCLUDED IN THE DOS DSECTS. * .* WE SOLVED THIS BY ADDING THESE LABELS AT THE END OF THE * .* DOS DSECTS, AND EQUATING THEM TO ZERO. BY EQUATING * .* THEM TO ZERO, WE INSURED THAT THE BRANCH-ON-EQUAL WOULD * .* NEVER BE TAKEN UNDER CMS (WE ALREADY KNEW THE ERROR CODE * .* WASN'T ZERO SINCE AN ERROR HAD DEFINITELY OCCURRED). * .* * .* NEXT, WE REALIZED THAT SIMPLY REASSEMBLING WITH * .* DIFFERENT DSECTS WOULD NOT SOLVE ALL THE PROBLEMS SINCE * .* INITIALLY THE CB'S WOULD BE IN MVS FORMAT, AND WOULD * .* ONLY CHANGE TO DOS FORMAT AFTER WE OPENED. (BILL HACKER * .* CALLS THESE CHAMELEON CONTROL BLOCKS, OR CCB'S.) * .* SINCE MOST OF THE MANIPULATION OF THE ACB CONCERNS FILLING * .* IN THE DDNAME AND OTHER FIELDS SO THAT VSAM CAN FIND THE * .* RIGHT DATASET, AND SINCE THIS MANIPULATION MUST CERTAINLY * .* OCCUR BEFORE OPEN, IT WOULD MAKE NO SENSE TO USE A DOS * .* ACB DSECT AT THAT POINT. * .* * .* AS IT TURNS OUT, 90% OF OUR REFERENCES TO THE ACB * .* OCCUR BEFORE OPEN, AND 90% OF THE REFERENCES TO THE RPL * .* OCCUR AFTER FIRST-USE. THEREFORE, USING AN MVS DSECT FOR * .* THE ACB AND A DOS DSECT FOR THE RPL SOLVES MOST OF THE * .* CMS PROBLEM. * .* * .* OUR SOLUTION FOR THE REMAINING 10% OF THE * .* REFERENCES WAS TO USE EXPLICIT BASE/DISPLACEMENT * .* ADDRESSING. FOR EXAMPLE, IF THE OPEN FAILED WE WANTED * .* TO EXTRACT THE ERROR CODE, WHICH WAS NOW IN DOS FORMAT, * .* SO WE WOULD CODE: * .* * .* IC R2,X'17'(RACB) * .* * .* AFTER WE KNEW THIS TECHNIQUE WOULD WORK, WE CLEANED * .* UP THE CODE A LITTLE BY ADDING LABELS AT THE END OF THE * .* MVS ACB DSECT FOR THE DOS FIELDS WE WOULD NEED AFTER OPEN, * .* AND ADDING LABELS AT THE END OF THE DOS RPL DSECT FOR * .* THE MVS FIELDS WE WOULD NEED BEFORE FIRST-USE. THE NAMES * .* WE SELECTED WERE IDENTICAL TO THE ORIGINAL EXCEPT THAT * .* THE ACB PREFIX WAS CHANGED TO 'DAC' (FOR DOS ACB), AND * .* THE DOS PREFIX WAS CHANGED TO 'ORP' (FOR OS RPL). THUS, * .* IN PLACE OF THE ABOVE INSTRUCTION WE COULD NOW CODE: * .* * .* IC R2,DACERFLG * .* * .* WE NOW FELT WE WERE ON THE VERGE OF EITHER A * .* BREAKTHROUGH OR A BREAKDOWN. SURE ENOUGH, WE WERE ABLE * .* TO DO AN OPEN AND ISSUE GETS TO OUR VSAM FILE. WHEN IT * .* CAME TO PUTS, HOWEVER, WE CAME DOWN WITH A BAD CASE OF * .* COMPUTATIONAL WHOOPING COUGH. * .* * .* THE LAST BUT NOT LEAST PROBLEM LEFT FOR US TO SOLVE * .* HAD TO DO WITH THE FACT THAT WE WERE NOT CORRECTLY * .* SETTING THE OPTCD FLAGS IN THE RPL. WE WERE USING THE * .* CORRECT LABELS FOR THE FLAG BYTES (RPLOPT1 AND RPLOPT2), * .* AND THE CORRECT LABELS FOR THE BITS (RPLKEY, RPLUPD, ETC.). * .* BUT, UNBEKNOWNST TO ANY OF US, IBM HAD SECRETELY REARRANGED * .* THE OPTCD BITS, NOT ONLY WITHIN EACH BYTE, BUT BETWEEN * .* BOTH OF THE TWO WE WERE USING. IN OTHER WORDS, IBM HAD * .* DECIDED TO REASSIGN THE BITS IN A (SEEMINGLY) RANDOM * .* MANNER WHEN THEY CODED THE DOS RPL DSECT. IT NOW MADE NO * .* SENSE TO CODE 'OI RPLOPT1,RPLKGE' IF THE KGE BIT WAS * .* ASSIGNED TO RPLOPT2 UNDER DOS. * .* * .* THE SOLUTION WE FOUND TO THIS LAST HITCH IS EMBODIED * .* IN THIS SHORT AND SWEET MACRO. OUR TASK IS TO CODE IN * .* ONE SOURCE MODULE THE LOGICAL NAMES OF THE OPTIONS WE * .* REQUIRE, AND TO HAVE THE MACRO SCRAMBLE, SHUFFLE, SORT, * .* ARRANGE, REARRANGE, REORDER, FILTER, TRANSLATE, * .* TRANSMOGRIFY, REGENERATE, RECONSTRUCT, AND/OR SUBTLY * .* CHANGE IN ANY WAY THAT IS TRULY 'TRANSPARENT TO THE USER' * .* THE ORDER OF THE BITS IT TURNS ON IN THE RPL. * .* * .* FORTUNATELY, A HANDY INNER MACRO ALREADY EXISTED * .* TO HELP US IN THIS TASK. MS1OPTS, ONE OF THE MS/1 (MACRO * .* SYSTEM/ONE) FAMILY OF HAPPY MACROS, IS DESIGNED * .* SPECIFICALLY TO ANALYSE A LIST OF OPTION NAMES, AND TO * .* RETURN TO THE CALLING MACRO A STRING OF 1'S AND 0'S. * .* THE CALLING MACRO PASSES A TABLE OF VALID OPTIONS TO * .* MS1OPTS, AND THE STRING RETURNED IS IN THE SAME LOGICAL * .* ORDER AS THIS TABLE, WITH 1'S REPRESENTED OPTIONS REQUESTED, * .* AND 0'S REPRESENTED OPTIONS NOT REQUESTED. * .* * .* IT NOW REMAINED ONLY TO CODE A MACRO (THIS ONE) * .* WHICH WOULD ACCEPT AS INPUT A LIST OF DESIRED OPTCD * .* NAMES, WHICH WOULD TRANSLATE THESE OPTIONS TO A * .* DIFFERENT BIT STRING ACCORDING TO WHETHOR MVS OR DOS * .* WAS GENERATING, AND WHICH WOULD MOVE THIS BIT STRING * .* INTO THE RPLOPT1 AND RPLOPT2 FIELDS. * .* * .* CALLS TO THIS MACRO NOW APPEAR IN PLACE OF THE * .* MVI INSTRUCTIONS IN THE ORIGINAL CODE. THIS APPROACH HAS * .* PAID OFF, AND ALL VSAM FUNCTIONS SUPPORTED PREVIOUSLY * .* UNDER MVS ARE NOW FULLY SUPPORTED UNDER CMS. * .* * .* - DEAN HANNOTTE, 11/02/78 * .* * .********************************************************************** COPY DMIGBLS INITIALIZE DMI/VS GLOBAL VARIABLES LCLC &O GENERATED OPERAND &LABEL DMILABEL MACRO=DMIVSAM GENERATE OPTIONAL LABEL .* GBLC &DMIVSAM SYSPARM OPTION AIF ('&DMIVSAM' EQ 'DOS').DOS .MVS MS1OPTS &OPTCD, ANALYSE THE OPTIONS TABLE=(LOC,DIR,SEQ,SKP,ASY,KGE,GEN,ECBIN, KEY,ADR,CNV,BWD,LRD,WAITX,UPD,NSP) AGO .MOVE * .DOS MS1OPTS &OPTCD, ANALYSE THE OPTIONS TABLE=(KEY,ADR,SEQ,DIR,ASY,SKP,CNV,UPD, KGE,GEN,NSP,NUP,LOC,UBF,BWD,LRD) .MOVE ANOP * &O SETC '=BL2''&MS1OPTS'' SET &DMIVSAM OPTCD=&OPTCD' MVC RPLOPT1(2),&O MEND