A former co-worker left us with thousands of lines of code looking like this. This is more a curiosity, since I rewrote everything he did in less obscure languages :-)
Nevertheless I'm curious. Is this meta-code or an actual language?
DATA DIVISION.
WORKING-STORAGE SECTION.
78 dialog-system VALUE "DIV".
01 Display-Error.
03 Display-Error-No PIC 9(4) comp-5.
03 Display-Details-1 PIC 9(4) comp-5.
03 Display-Details-2 PIC 9(4) comp-5.
05 Display-Details-3 PIC 9(4) comp-5.
COPY "DS-CNTRL.MF".
COPY "ThisApp.txt".
PROCEDURE DIVISION.
*---------------------------------------------------------------*
Main-Process SECTION.
PERFORM Program-Initialize
PERFORM Program-Body UNTIL EXIT-FLAG-TRUE
PERFORM Program-Terminate
.
*---------------------------------------------------------------*
Program-Initialize SECTION.
INITIALIZE Ds-Control-Block
INITIALIZE Data-block
MOVE Data-block-version-no
TO Ds-Data-Block-Version-No
MOVE Version-no TO Ds-Version-No
MOVE Ds-New-Set TO Ds-Control
MOVE "MyApp" TO Ds-Set-Name
.
*---------------------------------------------------------------*
Program-Body SECTION.
PERFORM Call-Dialog-System
.
*---------------------------------------------------------------*
Program-Terminate SECTION.
STOP RUN
.
*---------------------------------------------------------------*
Call-Dialog-System SECTION.
CALL dialog-system USING Ds-Control-Block,
Data-Block
IF NOT Ds-No-Error
MOVE Ds-System-Error TO Display-error
DISPLAY "DS ERROR NO: " Display-error-no
DISPLAY "Error Details(1) : " Display-Details-1
DISPLAY "Error Details(2) : " Display-Details-2
DISPLAY "Error Details(3) : " Display-Details-3
PERFORM Program-Terminate
END-IF
That's COBOL! http://en.wikipedia.org/wiki/Cobol
Sadly I knew it was COBOL instantly, thanks to the useless college courses I took on it in 2001. Even more sadly this is literally the first time I used those skills.
Definitely COBOL. Not really obscure as such just something that you hadn't seen before.
Also you have my sympathies for having to have read it.
That's Cobol Keyword list at this site helped to identify it.
I can't be completely certain, but it looks like COBOL.
Related
I have solved this problem in the sense I have code that does what I want, but I don't understand why it is necessary to do what I do, and I cannot see this behaviour documented, so I wonder if someone could explain why?
I am actually "porting" ncurses to Forth. More correctly I am writing some RISC-V assembly that lightly wraps around the C library calls to give Forth users an interface to ncurses.
This is what the code looks like in Forth:
: hello S" Hello, World!" ;
: goodbye S" Goodbye, World! " ;
: garish 1 color_red color_yellow init_pair ;
: cool 2 color_cyan color_black init_pair ;
: doit initscr clear start_color garish cool 1 color_pair attron 10 10 movew hello drop printw refresh getch 1 color_pair attroff ;
: endit 2 color_pair attron 30 30 movew goodbye drop printw refresh getch 2 color_pair attroff endwin ;
doit
endit
For those who don't know Forth this defines a few words then calls the doit and endit words to actually execute the program. But this isn't a question about Forth but about why I need to call clear (which is simply a wrapper around a call to the ncurses clear call) after I call initscr (again just a simple wrapper around a call to the ncurses function).
The assembly is shown below. 'CODEEND' and 'CODEHEADER' are macros that generate Forth function headings and 'TAILMOD' generates the return to the loop code - but the key point is you can see these are very light wrappers around the C calls:
CODEEND INITSCR, 0x01
#(--)
call initscr
la t0, STDSCR #store stdscr
sd a0, 0(t0)
TAILMOD t1
CODEHEADER CLEAR, INITSCR, 0x01
#( -- )
call clear
TAILMOD t1
If I don't call clear, then on every subsequent call of the doit endit pair I just see the previous output - i.e. initscr has not cleared the screen without this explicit call to clear.
Am I right in thinking that initscr should normally clear the screen on every invocation (at the next call of refresh)?
Is it just a function of my terminal type (this is a tty over ssh in this case) that I have to call clear or is there something else at work here?
Adding Just to be totally clear, I know the documentation says a call to refresh is required to clear the screen and I have done that but it doesn't work - that is implicit in the code I've posted where there is an explicit refresh but I am adding this to make it obvious to people who maybe don't grok Forth. (Originally where the clear is there was a refresh but it does not clear the screen on subsequent calls.)
Per manpage:
initscr also causes the first call to refresh(3x) to clear the screen.
You won't see any change on the screen until that refresh. Some functions (such as getch) do a refresh as a side-effect.
I have made android app that reads truck driver card (from tachograph) via otg smart card reader.
I can read all files on card from tree structure on image bellow.
But when I compare data that I read, and from some other public application, I have noticed that some files are fallowed by something that might be a key or signature
I do not know what underlined part represents nor how to read or generate it.
Without those "signatures" all data that I have is useless, but if I hard code those underlined parts (from other apps) in my ddd file, everything works fine
The most I have found is that
05 04 - Current usage Data
01 - means there is still a signature (gen 1)
00 80 - 0x0080 = 128 dec
Also I have read card certificate and ca certificate from card but didn't find is there any correlation with underlined part of problem.
Thanks to #nvf I found explication and solution in document
Part of responses .ddd that start with "01 00 80" represent digital signature of hash value on previously selected file.
To get digital signature you should select file, execute command to perform hash of file, and then execute command to get 128 bytes digital signature.
I was looking through the 1975 Oregon Trail Basic Code and found this line in it:
PRINT LIN(2)
I have searched quite a few places but can't find any reference to it.
Can anyone tell me what this means?
Edit:
Sorry, I was wondering what the PRINT LIN(2) meant. Does anyone know what that means?
"Oregon Trail" source of 1975 at www.filfre.net/misc/oregon1975.bas was written in BASIC for a HP-2100 system.
This HP-2100 system was a series of minicomputers produced by Hewlett-Packard.
This system run an interpreted BASIC named "HP Time-Shared BASIC".
This is the reference manual of "TimeShared BASIC/2000 Level F".
About:
PRINT LIN(2)
Generates a carriage return and 2 (two) line feeds.
"Oregon Trail" for year 1978 at www.filfre.net/misc/oregon1978.bas was written using BASIC for "CDC Cyber range of mainframe-class supercomputers of Control Data Corporation (CDC)".
Documentation
http://bitsavers.org/pdf/cdc/cyber/lang/basic/
19983900K_BASIC_Version_3_Reference_Manual_Aug84.pdf
I compare both sources (strip line number without reference by THEN, GOTO or GOSUB) at
Oregon Trail Compare
We are working with SCOSTA smart card with ISO7816-4 APDU Commands.
I had create file structure but didn't understand how to set security Access Condition in Compact and Extended Format
For Example.
I am using TLV structure for Creating File MF,DF,EF,SE etc
Deticated File will have following FCP:
Tag 8C
Len 08
Security Attribute AM 7F
VALUE FF Delete File(Self):Never
VALUE FF Terminate DF:Never
VALUE 22 Activate File:(SE#2)
VALUE 22 Deactivate File:(SE#2)
VALUE 22 Create File EF:(SE#2)
VALUE 22 Create File DF:(SE#2)
VALUE FF Delete File(child):Never
So My Question is :
Where from VALUE 22 Set and what is the meaning of SE#2 ?
How to calculate AM Byte?
I refer ISO/IEC 7816-4:2005(E) Document Page No:24-25
Tag 8C indicates an access rule in compact format. There an Access Mode Byte (7F) is followed by as many Security Condition Bytes as bits are set in the access mode byte. The example looks reasonable, even if in my opinion, it would be more intuitive, to leave out the bits (and corresponding SCBs) for which only a NEVER security condition byte follows. (An operation not explicitly allowed, should be rejected anyway).
The coding of the Access mode byte for a DF is found in table 16 and the encoding of the security condition byte is in table 20 of ISO 7816-4.
SE#2 means, that the key IDs necessary for User Authentication, External Authentication and Secure Messaging are determined by Security Environment 2, the value 22 means, that in your case only an external authentication is necessary.
Is it in anyway possible to increase the number of suggests that your extension may show in the omnibox?
By default it looks like 5 rows is the limit. I've read about a command line switch to change the number of rows (--omnibox-popup-count) but I am really interested in dynamically being able to set this in my extension.
5 rows isn't really enough for the information my extension want to show.
[Update 2018 - thanx version365 & Aaron!]
» Not hardcoded anymore! chrome://flags/#omnibox-ui-max-autocomplete-matches . Credit goes to #version365 answering below: http://stackoverflow.com/a/47806290/234309 « – Aaron Thoma
..[historical] detail: since the removal of --omnibox-popup-count flag (http://codereview.chromium.org/2013008) in May 2010 the number [was] hardcoded:
const size_t AutocompleteResult::kMaxMatches = 6;
a discussion two years later on the chromium-discuss mailing list about the 'Omnibox default configuration' "concluded"
"On lower performing machines generating more result would slow down the result display. The current number look like a good balance."
[which is not a very valid argument, considering the probably infinitesimal overhead retrieving more items than the hard-wired number]
why the heck is there no chromium fork that removes stupid UX limitations like this (or the no tabbar in fullscreen mode)^^
Since there is no more --omnibox-popup-count flag; you can use another flag which is new.
chrome://flags/#omnibox-ui-max-autocomplete-matches lets you select a maximum of 12 rows.
In fact there is no more --omnibox-popup-count flag
http://code.google.com/p/chromium/issues/detail?id=40083
So I think there is no way to enlarge the omnibox.