I am trying to familiarize myself with COBOL. I try to start the following program:
identification division.
program-id. Bestand.
date-written. 08.05.2020
environment division.
input-output section.
file-control.
select bestand-datei-ein assign to
"C:\Users\Michael\Desktop\Microfocus\Programme\aus.txt".
select bestand-datei-aus assign to
"C:\Users\Michael\Desktop\Microfocus\Programme\aus.txt".
data division.
file section.
fd bestand-datei-ein label records are omitted.
01 bestand-satz-ein.
05 e-teile-nr PIC X(6).
05 e-bestand-menge PIC 9(5).
05 e-eingang-menge PIC 9(4).
05 e-stueck-preis PIC 999V99.
fd bestand-datei-aus label records are omitted.
01 bestand-satz-aus.
05 a-teile-nr PIC X(6).
05 filler PIC X(4).
05 a-bestand-menge PIC 9(5).
05 filler PIC X(3).
05 a-eingang-menge PIC 9(4).
05 filler PIC X(3).
05 a-stueck-preis PIC 999.99.
05 filler PIC X(3).
05 a-bestand-menge-neu PIC 9(5).
05 filler PIC X(3).
05 a-kosten PIC 9(6).99.
01 a PIC X.
working-storage section.
01 bestand-datei-ein-ende PIC X.
procedure division.
a000-haupt-steuerung-routine.
open input bestand-datei-ein
output bestand-datei-aus.
move 'N' to bestand-datei-ein-ende.
read bestand-datei-ein
at end move 'J' to bestand-datei-ein-ende.
perform b010-listen-bestandsdaten
until bestand-datei-ein-ende = 'J'.
close bestand-datei-aus
bestand-datei-ein.
accept a.
stop run.
b010-listen-bestandsdaten.
move spaces to bestand-satz-aus.
move e-teile-nr to a-teile-nr.
move e-bestand-menge to a-bestand-menge.
move e-eingang-menge to a-eingang-menge.
move e-stueck-preis to a-stueck-preis.
add e-bestand-menge, e-eingang-menge
giving a-bestand-menge-neu.
multiply a-bestand-menge-neu by e-stueck-preis
giving a-kosten.
read bestand-datei-ein
at end
move 'J' to bestand-datei-ein-ende.
I always get the error message "File not found: C: \ Users \ Michael \ Desktop \ Microfocus \ Program \ aus.txt" when I start the program and the should be opened.
I work with Micro Focus Visual Cobol for Visual Studio
Any idea ?
From comment:
The problem has now been solved. The file names were not displayed correctly in the code (cut and paste errors). It should read "ein.txt" and aus.txt. The problem was that the file names in the file system were set so that the extension is not displayed. I named the input file "ein.txt" and basically created a file named "ein.txt.txt". Therefore the file was not found.
Related
I have a program that decrypts a ciphertext (which I don't control) using this example from the go docs: https://pkg.go.dev/crypto/cipher#NewCBCDecrypter
The problem is this part:
// If the original plaintext lengths are not a multiple of the block
// size, padding would have to be added when encrypting, which would be
// removed at this point. For an example, see
// https://tools.ietf.org/html/rfc5246#section-6.2.3.2
My original plaintext length is indeed not a multiple of the block size, so I need to remove the padding. How can I do this? If I do not remove the padding, I can not decompress the plaintext because of https://github.com/golang/go/issues/47809 which go maintainers made clear is very strict about gzip compliance on purpose. Currently my workaround is to invoke gunzip as a shell command which can successfully decompress the plaintext (ignoring the trailing padding).
I checked the ietf link but I found no examples (or at least no go examples)
It turns out the encrypter and decrypter have to agree on a padding scheme in advance. In my case, the encrypter was using the padding scheme described here: https://www.rfc-editor.org/rfc/rfc5652#section-6.3
In other words, the plaintext is padded with 0x01 if there is one byte of padding, 0x02 0x02 if there are 2 bytes of padding, 0x03 0x03 0x03, etc.
So for a toy example, assume block size is 4 bytes. Here are some example plaintexts:
plaintext ... plaintext with padding
01 01 03 03 03
01 02 01 02 02 02
01 02 03 01 02 03 01
01 02 03 04 01 02 03 04 04 04 04 04
Therefore, I was able to remove plaintext padding using:
func removePadding(pt []byte) []byte {
padLength := int(pt[len(pt)-1])
return pt[:len(pt)-padLength]
}
See also: https://crypto.stackexchange.com/a/2805
Hi I was wondering if yall could help me figure this error out. Im rather new to cobol as it is my first (and only) cobol class in my major.
I keep getting this error lab3a.cob:23: Error: syntax error, unexpected "Identifier", expecting EXTERNAL or GLOBAL
whenever I try to compile. And I cant seem to see what I'm doing wrong.
My Code
IDENTIFICATION DIVISION.
PROGRAM-ID. "LAB3A".
Author. Fielding Featherston
* Takes inputs from file and seperates.
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT InFile
ASSIGN to "lab3-in.dat"
ORGANIZATION is LINE SEQUENTIAL.
DATA DIVISION.
FILE SECTION.
FD InFile.
01 InString.
05 PIC X(13).
05 Instrument PIC X(12).
88 Brass value "Bugle" "Flugelhorn"
"Sousaphone" "Trombone"
"Trumpet" "Tuba".
88 Percussion value "Bass Drum" "Bells" "Bongos"
"Castanets" "Chimes" "Cymbals"
"Snare Drum" "Xylophone".
88 Strings value "Banjo" "Bass" "Cello" "Guitar"
"Harp" "Lyre"
"Mandolin" "Violin".
88 Woodwind value "Bagpipes" "Bassoon" "Clarinet"
"Flute" "Oboe"
"Piccolo" "Saxophone".
WORKING-STORAGE SECTION.
01 BrassCount PIC 9(3).
01 PerCount PIC 9(3).
01 StringCount PIC 9(3).
01 WoodCount PIC 9(3).
01 OtherCount PIC 9(3).
01 BrassStr PIC ZZ9.
01 PerStr PIC ZZ9.
01 StringStr PIC ZZ9.
01 WoodStr PIC ZZ9.
01 OtherStr PIC ZZ9.
01 InStringLength PIC 99.
01 EndFileStr PIC X VALUE "n".
88 EndFile VALUE "y"
When Set to False is "y".
PROCEDURE DIVISION.
000-Main.
Open Input InFile
Perform until EndFile
Read InFile
At end
Set EndFile to FALSE
Not at End
PERFORM 100-SeperateStrings
PERFORM 200-ClassCount
END-READ
END-PERFORM
CLOSE InFile
Move BrassCount to BrassStr
Move PerCount to PerStr
Move StringCount to StringStr
Move WoodCount to WoodStr
Move OtherCount to OtherStr
DISPLAY "Counts"
DISPLAY " Brass: " FUNCTION TRIM(BrassStr)
DISPLAY " Percussion: " FUNCTION TRIM(PerStr)
DISPLAY " String: " FUNCTION TRIM(StringStr)
DISPLAY " Woodwind: " FUNCTION TRIM(WoodStr)
DISPLAY " OTHER: " FUNCTION TRIM(OtherStr)
STOP RUN.
100-SeperateStrings.
MOVE FUNCTION Length(InString) to InStringLength
UNSTRING InString (14:InStringLength)
INTO Instrument
END-UNSTRING.
200-ClassCount.
IF Brass
Add 1 to BrassCount
ELSE IF Percussion
Add 1 to PerCount
ELSE IF Strings
Add 1 to StringCount
ELSE IF Woodwind
Add 1 to WoodCount
ELSE
Add 1 to OtherCount
END-IF.
An EXTERNAL or GLOBAL clause in the context of the error may only occur in a record description entry; that is, a data entry that begins with 1 or 01. Given that the error occurs between two 88 level items, it appears the compiler is confused about where it is while scanning the source code.
There is some unusual formatting that may be creating a problem with an the compiler. In particular, line 22 contains a number of TAB characters that should not, but may, confuse the compiler. Also, lines 33 and 46 contain a number of TAB characters at the end of each source line causing the lines to exceed 72 characters.
Another possible issue is expansion of tabs, whether each TAB character is replaced by 4 or 8 spaces by the compiler. Again this will affect whether the text exceeds 72 characters. In the absence of a SOURCE FORMAT directive, source text after column 72 is ignored.
Until you know the effect that tabs have on the source code, I suggest replacing all tabs with spaces.
I am trying to read data from sony felica card using pc/sc transparent session and transceive data object.
The response I am getting is for a read without encryption command is
c0 03 00 90 00 92 01 00 96 02 00 00 97 82 00 + Data
But according to the protocol, the response should be
c0 03 00 90 00 92 01 00 96 02 00 00 97 + Data
I am unable to figure out the last 82 00 appended in the response from the card.
Now when I try to authenticate with the card I get
c0 03 01 6F 01 90 00
which is a error in pc/sc. I want to resolve these extra bytes 82 00 which I believe will solve the issue with all the commands which require authentication and encryption.
The response data is BER-TLV encoded (see PC/SC 2.02, Part 3).
In BER-TLV encoding there are several possibilities to encode tag 0x97 with two octets of data 0xD0D1, e.g.:
97|02|D0D1 -- short form (see parsed)
97|8102|D0D1 -- long form with one octet with length (see parsed)
97|820002|D0D1 -- long form with two octets with length (see parsed)
97|83000002|D0D1 -- long form with three octets with length (see parsed)
...
Your reader is using two octets for sending the length of ICC Response data object (which is perfectly valid).
You should parse the response properly...Good luck!
PS: The above means, that the Data part of your truncated responses still contains one extra byte with the response length (i.e. Len|Data)
I'm trying to determine Visual Studio version (2002/2003, 2005, 2008, 2010, 2012, 2013, 2015) from the .obj file generated with the link time code generation option.
The file I have, generated with MSVC2012, has following COFF header contents:
File Header
+0 00 00 Machine - Unknown Machine
+2 FF FF NumberOfSections
+4 01 00 4C 01 TimeDateStamp
+8 70 94 F9 55 PointerToSymbolTable
+12 38 FE B3 0C NumberOfSymbols
+16 A5 D9 SizeOfOptionalHeader
+18 AB 4D Characteristics
Optional Header
+20 AC 9B Magic
+22 D6 B6 Linker Version Major/Minor
It seems that the initial 4 bytes being 00,00,FF,FF mark it as a LTCG object, and what follows is proprietary. None of the usual file header members make "sense" (maybe the timestamp is OK, I didn't check).
Does anyone know offhand if any part of this header is compiler-specific? All I need to determine is the MSVC major version used to compile the object...
It appears that there is a version, coded as <MAJOR:16:LE> 0x80 <MINOR:16:LE>, stored shortly after the header. E.g.:
17.00.61030 -> 0x11.0xEE66 -> 11 00 80 66 EE
19.00.23026 -> 0x13.0x59F2 -> 13 00 80 F2 59
What's needed is to figure out how to get to it reliably by offsets from preceding data.
This is a related question, with no resolution...
TL,DR :
You can't get the compiler version with this file format, I guess ...
Complete answer :
It looks like some variation of the "anonymous file format", described in the "winnth.h" by various ANON_OBJECT_HEADER_XXX structures (replace XXX by V2 or BIGOBJ).
Here is a copy of the ANON_OBJECT_HEADER_BIGOBJ found in winnt.h :
typedef struct ANON_OBJECT_HEADER_BIGOBJ {
/* same as ANON_OBJECT_HEADER_V2 */
WORD Sig1; // Must be IMAGE_FILE_MACHINE_UNKNOWN
WORD Sig2; // Must be 0xffff
WORD Version; // >= 2 (implies the Flags field is present)
WORD Machine; // Actual machine - IMAGE_FILE_MACHINE_xxx
DWORD TimeDateStamp;
CLSID ClassID; // CLSID is a 16 bytes struct (not original comment)
DWORD SizeOfData; // Size of data that follows the header
DWORD Flags; // 0x1 -> contains metadata
DWORD MetaDataSize; // Size of CLR metadata
DWORD MetaDataOffset; // Offset of CLR metadata
/* bigobj specifics */
DWORD NumberOfSections; // extended from WORD
DWORD PointerToSymbolTable;
DWORD NumberOfSymbols;
} ANON_OBJECT_HEADER_BIGOBJ;</code>
The description match:
Sig1 : 00 00
Sig2 : FF FF
Version : >=2
Machine : 0x14c`
The other header structures (i.e, ANON_OBJECT_HEADER and ANON_OBJECT_HEADER_V2) are basically the same, but with less fields.
For the Version field, I found some information here :
http://www.geoffchappell.com/studies/msvc/link/dump/infiles/obj.htm
Looks like the Version field is "1" for anonymous files, and it seems like the anonymous files and the so called "import files" shared the same characteristics, only that Version = 0 for import file format (I do not really know what it is admittedly).
But yeah, by just looking at the header, it seems that we have no information on what compiler version was used. And even then, when looking at .obj files generated with the /GL switch, they do not exactly follow this format and I didn't find much information about them. I'll be glad that someone prove me wrong.
I have an old VB executable that has been used for a long time in my project.
The current implementation of the application contains a debug window that's
not needed any more.
Of course, the source code was lost and can not be modified.
My idea is to modify the HEX code of the instance that's opening the annoying debug window.
For that purpose, I use VB Decompiler by DotFix software, and I suppose that I found the code responsible for that instance. Unfortunately, I can't understand how it works.
Let's see the disassemble code:
loc_8F420C: var_8A = 0
loc_8F4219: If (Len(var_88) = &H30) Then
loc_8F4225: Call {3014B1BF-8A2C-23D7-B50400C24F280C20}.Method_arg_12 (var_88)
loc_8F4233: Call {3014B1BF-8A2C-23D7-B50400C24F280C20}.Method_arg_16 (var_108)
loc_8F423D: If CBool(var_108) Then
loc_8F424D: Me.Global.Unload Me
loc_8F4258: Else
loc_8F425A: var_8A = &HFF
...
loc_8F43B0: End If
loc_8F43B3: Else
At the first sight var_108 seems a bool variable that is the one setting the debug window. Can I implicitly put in loc_8F423D: If CBool(false/true) Then to stop this window from launching?
Can anyone explain to me what are those Call {#######-####-####-################}.Method_arg_## from above?
PEiD detect compiler:
Microsoft Visual Basic 5.0 / 6.0 [Overlay]
Part 2:
It took me a long time to get the new idea - the right one, possibly. Let's take a look at the assembly code:
004F420C: 70 FStI2 var_8A <- loc_8F420C: var_8A = 0
Looks like loc_8F4219: If (Len(var_88) = &H30) Then
004F420F: 6C ILdRf var_88
004F4212: 4A FnLenStr Len()
004F4213: F5 LitI4: 48 (0x30)
Let's find the next code snippets:
004F4218: C7 EqI4 =
004F4219: 1C BranchF 004F43B3
Our Call methods looks like :
004F421C: 6C ILdRf var_88 < - (var_88) from Call
004F421F: 22 ImpAdLdPr
004F4222: 58 MemLdPr
004F4225: 0D VCallHresult var_88.vtable[12] <- Method_arg_12
004F422A: 04 FLdRfVar var_108 <- (var_108) possible CALL/BACK
004F422D: 22 ImpAdLdPr
004F4230: 58 MemLdPr
004F4233: 0D VCallHresult var_108.vtable[16] <- Method_arg_16
004F4238: 6C ILdRf var_108 <- (var_108) 70% sure is RESPONSE(true/false)
And now the most interesting parts of that annoying P-Code&Assembly, we find the if instance that verifies if the Debug Windows is needed. If we look at P-Code we can see that if has the form:
loc_8F423D: If CBool(var_108) Then
loc_8F424D: Me.Global.Unload Me
loc_8F4258: Else
loc_8F425A: var_8A = &HFF
And now look at the Address - if is true execute address 00F424D / 8F424D else jump outside to 004F4258
004F423B: FC52 CBoolI4
004F423D: 1C BranchF 004F4258
004F4240: 6C ILdRf param_8
004F4243: FD9C FStAdNoPop
004F4247: 05 ImpAdLdRf
004F424A: 24 NewIfNullPr GLOBAL
004F424D: 0D VCallHresult Global._Unload(object As IDispatch)
004F4252: 1A FFree1Ad var_90
004F4255: 1E Branch 004F43B0
004F4258: loc_004F423D
004F4258: F4 LitI2_Byte: 255 (True)
Possibly, if I change the 004F423D: 1C BranchF 004F4258 so that it points to another address 004F424D, logically that might do the trick.
004F423D: 1C BranchF 004F424D
Now I'm trying to find that address with OllyDbg - to test if that helps. If I succeed I will write part 3.
Does anyone have some other ideas?