I understand the shape of the bytes behind a PACKED-DECIMAL number when on a Big-Endian machine. What I have not been able to discover is what shape would those bytes take on a Little-Endian machine.
Note: The reason I believe there does exist a separate format for such is because the IBM MQ Encoding field has the following values:-
MQENC_DECIMAL_NORMAL
MQENC_DECIMAL_REVERSED
Of MQENC_DECIMAL_REVERSED it simply says:-
Packed-decimal integers are represented in the same way as MQENC_DECIMAL_NORMAL, but with the bytes arranged in reverse order. The bits within each byte are arranged in the same way as MQENC_DECIMAL_NORMAL.
Can anyone corroborate or refute this description?
For example, the number +123.45 stored in a PIC 9(3)V99 COMP-3 would have the following bytes:-
12 34 5C
The above quote suggests to me that if in reversed, the same packed decimal number would be represented on a Little-Endian machine as:-
5C 34 12
N.B. I have not tagged this question with ibm-mq, as I don't really think the crux of my question has anything to do with IBM MQ. It is simply the reason I am asking.
It looks like packed data is stored in "normal" byte order.
The following program was compiled with OpenCOBOL 1.1.0 on Ubuntu 16.04 on a Lenovo ThinkPad...
ID Division.
Program-ID. testcmp3.
Environment Division.
Input-Output Section.
File-Control.
Select OUTPUT01 Assign To './output01'
Status OUTPUT01-STATUS.
Data Division.
File Section.
FD OUTPUT01
Record 16
Block 0
Recording F.
01 OUTPUT01-REC PIC X(016).
Working-Storage Section.
01 CONSTANTS.
05 MYNAME PIC X(008) VALUE 'testcmp3'.
01 WS-OUTPUT01-REC.
05 WS-OUT-S94COMP PIC S9(004) COMP VALUE +0.
05 FILLER PIC X(001) VALUE HIGH-VALUES.
05 WS-OUT-S95COMP3 PIC S9(005) COMP-3 VALUE +0.
05 FILLER PIC X(008) VALUE SPACES.
01 WORK-AREAS.
05 OUTPUT01-STATUS PIC X(002) VALUE ZEROES.
Procedure Division.
OPEN OUTPUT OUTPUT01
IF OUTPUT01-STATUS NOT = '00'
DISPLAY
MYNAME
' open of OUTPUT01 status = '
OUTPUT01-STATUS
END-IF
PERFORM 100-WRITE 100 TIMES
CLOSE OUTPUT01
STOP RUN.
100-WRITE.
WRITE OUTPUT01-REC FROM WS-OUTPUT01-REC
ADD 1 TO WS-OUT-S94COMP
ADD 1 TO WS-OUT-S95COMP3
.
...with the option binary-byteorder set to native.
The resulting file, displayed with the hexdump program, follows.
00000000 00 00 ff 00 00 0c 20 20 20 20 20 20 20 20 20 20 |...... |
00000010 01 00 ff 00 00 1c 20 20 20 20 20 20 20 20 20 20 |...... |
00000020 02 00 ff 00 00 2c 20 20 20 20 20 20 20 20 20 20 |....., |
00000030 03 00 ff 00 00 3c 20 20 20 20 20 20 20 20 20 20 |.....< |
00000040 04 00 ff 00 00 4c 20 20 20 20 20 20 20 20 20 20 |.....L |
00000050 05 00 ff 00 00 5c 20 20 20 20 20 20 20 20 20 20 |.....\ |
00000060 06 00 ff 00 00 6c 20 20 20 20 20 20 20 20 20 20 |.....l |
00000070 07 00 ff 00 00 7c 20 20 20 20 20 20 20 20 20 20 |.....| |
00000080 08 00 ff 00 00 8c 20 20 20 20 20 20 20 20 20 20 |...... |
00000090 09 00 ff 00 00 9c 20 20 20 20 20 20 20 20 20 20 |...... |
000000a0 0a 00 ff 00 01 0c 20 20 20 20 20 20 20 20 20 20 |...... |
000000b0 0b 00 ff 00 01 1c 20 20 20 20 20 20 20 20 20 20 |...... |
000000c0 0c 00 ff 00 01 2c 20 20 20 20 20 20 20 20 20 20 |....., |
000000d0 0d 00 ff 00 01 3c 20 20 20 20 20 20 20 20 20 20 |.....< |
000000e0 0e 00 ff 00 01 4c 20 20 20 20 20 20 20 20 20 20 |.....L |
000000f0 0f 00 ff 00 01 5c 20 20 20 20 20 20 20 20 20 20 |.....\ |
00000100 10 00 ff 00 01 6c 20 20 20 20 20 20 20 20 20 20 |.....l |
00000110 11 00 ff 00 01 7c 20 20 20 20 20 20 20 20 20 20 |.....| |
00000120 12 00 ff 00 01 8c 20 20 20 20 20 20 20 20 20 20 |...... |
00000130 13 00 ff 00 01 9c 20 20 20 20 20 20 20 20 20 20 |...... |
00000140 14 00 ff 00 02 0c 20 20 20 20 20 20 20 20 20 20 |...... |
00000150 15 00 ff 00 02 1c 20 20 20 20 20 20 20 20 20 20 |...... |
00000160 16 00 ff 00 02 2c 20 20 20 20 20 20 20 20 20 20 |....., |
00000170 17 00 ff 00 02 3c 20 20 20 20 20 20 20 20 20 20 |.....< |
00000180 18 00 ff 00 02 4c 20 20 20 20 20 20 20 20 20 20 |.....L |
00000190 19 00 ff 00 02 5c 20 20 20 20 20 20 20 20 20 20 |.....\ |
000001a0 1a 00 ff 00 02 6c 20 20 20 20 20 20 20 20 20 20 |.....l |
000001b0 1b 00 ff 00 02 7c 20 20 20 20 20 20 20 20 20 20 |.....| |
000001c0 1c 00 ff 00 02 8c 20 20 20 20 20 20 20 20 20 20 |...... |
000001d0 1d 00 ff 00 02 9c 20 20 20 20 20 20 20 20 20 20 |...... |
000001e0 1e 00 ff 00 03 0c 20 20 20 20 20 20 20 20 20 20 |...... |
000001f0 1f 00 ff 00 03 1c 20 20 20 20 20 20 20 20 20 20 |...... |
00000200 20 00 ff 00 03 2c 20 20 20 20 20 20 20 20 20 20 | ...., |
00000210 21 00 ff 00 03 3c 20 20 20 20 20 20 20 20 20 20 |!....< |
00000220 22 00 ff 00 03 4c 20 20 20 20 20 20 20 20 20 20 |"....L |
00000230 23 00 ff 00 03 5c 20 20 20 20 20 20 20 20 20 20 |#....\ |
00000240 24 00 ff 00 03 6c 20 20 20 20 20 20 20 20 20 20 |$....l |
00000250 25 00 ff 00 03 7c 20 20 20 20 20 20 20 20 20 20 |%....| |
00000260 26 00 ff 00 03 8c 20 20 20 20 20 20 20 20 20 20 |&..... |
00000270 27 00 ff 00 03 9c 20 20 20 20 20 20 20 20 20 20 |'..... |
00000280 28 00 ff 00 04 0c 20 20 20 20 20 20 20 20 20 20 |(..... |
00000290 29 00 ff 00 04 1c 20 20 20 20 20 20 20 20 20 20 |)..... |
000002a0 2a 00 ff 00 04 2c 20 20 20 20 20 20 20 20 20 20 |*...., |
000002b0 2b 00 ff 00 04 3c 20 20 20 20 20 20 20 20 20 20 |+....< |
000002c0 2c 00 ff 00 04 4c 20 20 20 20 20 20 20 20 20 20 |,....L |
000002d0 2d 00 ff 00 04 5c 20 20 20 20 20 20 20 20 20 20 |-....\ |
000002e0 2e 00 ff 00 04 6c 20 20 20 20 20 20 20 20 20 20 |.....l |
000002f0 2f 00 ff 00 04 7c 20 20 20 20 20 20 20 20 20 20 |/....| |
00000300 30 00 ff 00 04 8c 20 20 20 20 20 20 20 20 20 20 |0..... |
00000310 31 00 ff 00 04 9c 20 20 20 20 20 20 20 20 20 20 |1..... |
00000320 32 00 ff 00 05 0c 20 20 20 20 20 20 20 20 20 20 |2..... |
00000330 33 00 ff 00 05 1c 20 20 20 20 20 20 20 20 20 20 |3..... |
00000340 34 00 ff 00 05 2c 20 20 20 20 20 20 20 20 20 20 |4...., |
00000350 35 00 ff 00 05 3c 20 20 20 20 20 20 20 20 20 20 |5....< |
00000360 36 00 ff 00 05 4c 20 20 20 20 20 20 20 20 20 20 |6....L |
00000370 37 00 ff 00 05 5c 20 20 20 20 20 20 20 20 20 20 |7....\ |
00000380 38 00 ff 00 05 6c 20 20 20 20 20 20 20 20 20 20 |8....l |
00000390 39 00 ff 00 05 7c 20 20 20 20 20 20 20 20 20 20 |9....| |
000003a0 3a 00 ff 00 05 8c 20 20 20 20 20 20 20 20 20 20 |:..... |
000003b0 3b 00 ff 00 05 9c 20 20 20 20 20 20 20 20 20 20 |;..... |
000003c0 3c 00 ff 00 06 0c 20 20 20 20 20 20 20 20 20 20 |<..... |
000003d0 3d 00 ff 00 06 1c 20 20 20 20 20 20 20 20 20 20 |=..... |
000003e0 3e 00 ff 00 06 2c 20 20 20 20 20 20 20 20 20 20 |>...., |
000003f0 3f 00 ff 00 06 3c 20 20 20 20 20 20 20 20 20 20 |?....< |
00000400 40 00 ff 00 06 4c 20 20 20 20 20 20 20 20 20 20 |#....L |
00000410 41 00 ff 00 06 5c 20 20 20 20 20 20 20 20 20 20 |A....\ |
00000420 42 00 ff 00 06 6c 20 20 20 20 20 20 20 20 20 20 |B....l |
00000430 43 00 ff 00 06 7c 20 20 20 20 20 20 20 20 20 20 |C....| |
00000440 44 00 ff 00 06 8c 20 20 20 20 20 20 20 20 20 20 |D..... |
00000450 45 00 ff 00 06 9c 20 20 20 20 20 20 20 20 20 20 |E..... |
00000460 46 00 ff 00 07 0c 20 20 20 20 20 20 20 20 20 20 |F..... |
00000470 47 00 ff 00 07 1c 20 20 20 20 20 20 20 20 20 20 |G..... |
00000480 48 00 ff 00 07 2c 20 20 20 20 20 20 20 20 20 20 |H...., |
00000490 49 00 ff 00 07 3c 20 20 20 20 20 20 20 20 20 20 |I....< |
000004a0 4a 00 ff 00 07 4c 20 20 20 20 20 20 20 20 20 20 |J....L |
000004b0 4b 00 ff 00 07 5c 20 20 20 20 20 20 20 20 20 20 |K....\ |
000004c0 4c 00 ff 00 07 6c 20 20 20 20 20 20 20 20 20 20 |L....l |
000004d0 4d 00 ff 00 07 7c 20 20 20 20 20 20 20 20 20 20 |M....| |
000004e0 4e 00 ff 00 07 8c 20 20 20 20 20 20 20 20 20 20 |N..... |
000004f0 4f 00 ff 00 07 9c 20 20 20 20 20 20 20 20 20 20 |O..... |
00000500 50 00 ff 00 08 0c 20 20 20 20 20 20 20 20 20 20 |P..... |
00000510 51 00 ff 00 08 1c 20 20 20 20 20 20 20 20 20 20 |Q..... |
00000520 52 00 ff 00 08 2c 20 20 20 20 20 20 20 20 20 20 |R...., |
00000530 53 00 ff 00 08 3c 20 20 20 20 20 20 20 20 20 20 |S....< |
00000540 54 00 ff 00 08 4c 20 20 20 20 20 20 20 20 20 20 |T....L |
00000550 55 00 ff 00 08 5c 20 20 20 20 20 20 20 20 20 20 |U....\ |
00000560 56 00 ff 00 08 6c 20 20 20 20 20 20 20 20 20 20 |V....l |
00000570 57 00 ff 00 08 7c 20 20 20 20 20 20 20 20 20 20 |W....| |
00000580 58 00 ff 00 08 8c 20 20 20 20 20 20 20 20 20 20 |X..... |
00000590 59 00 ff 00 08 9c 20 20 20 20 20 20 20 20 20 20 |Y..... |
000005a0 5a 00 ff 00 09 0c 20 20 20 20 20 20 20 20 20 20 |Z..... |
000005b0 5b 00 ff 00 09 1c 20 20 20 20 20 20 20 20 20 20 |[..... |
000005c0 5c 00 ff 00 09 2c 20 20 20 20 20 20 20 20 20 20 |\...., |
000005d0 5d 00 ff 00 09 3c 20 20 20 20 20 20 20 20 20 20 |]....< |
000005e0 5e 00 ff 00 09 4c 20 20 20 20 20 20 20 20 20 20 |^....L |
000005f0 5f 00 ff 00 09 5c 20 20 20 20 20 20 20 20 20 20 |_....\ |
00000600 60 00 ff 00 09 6c 20 20 20 20 20 20 20 20 20 20 |`....l |
00000610 61 00 ff 00 09 7c 20 20 20 20 20 20 20 20 20 20 |a....| |
00000620 62 00 ff 00 09 8c 20 20 20 20 20 20 20 20 20 20 |b..... |
00000630 63 00 ff 00 09 9c 20 20 20 20 20 20 20 20 20 20 |c..... |
00000640
The draft standard document ISO/IEC CD2.1 1989:202x says of the USAGE PACKED-DECIMAL phrase...
The USAGE PACKED-DECIMAL clause specifies that a radix of 10 is used
to represent a numeric item in the storage of the computer.
Furthermore, this clause specifies that each digit position shall
occupy the minimum possible configuration in computer storage. Each
implementor specifies the precise effect of the USAGE PACKED-DECIMAL
clause upon the alignment and representation of the data item in the
storage of the computer, including the representation of any algebraic
sign. Sufficient computer storage shall be allocated by the
implementor to contain the maximum range of values implied by the
associated decimal picture character-string. If the WITH NO SIGN
phrase is specified the representation of the data item in the storage
of the computer reserves no storage for representing any sign value.
The PICTURE character string of the data item shall not contain the
symbol ‘S’; the data item is always considered to have a zero, or
positive value.
Related
I am using Airnef (and the PTPIP protocol) to download pictures from my Nikon Z50 camera through Wi-Fi.
It works perfectly in some cases, but in other cases the transfer is slowing down until the camera has been disconnected.
I have read the associated documentation (available here https://www.testcams.com/airnef/) and seen that a similar issue has been encountered while the program has been developed, which seemed to be caused by a bug in the Nikon firmware which lead to some memory issues and a possible disconnection. The same issue seems to have been found during gphoto2 development (https://sourceforge.net/p/gphoto/mailman/gphoto-devel/thread/20190107075304.GC4614%40jet.franken.de/)
From what I understand, the parameters "maxgetobjbuffersizekb" and "maxgetobjtransferzekb" have been introduced to fix a such issue by trying to limit the requested sizes on the camera to transfer image, however it does not seems to work in my case.
I have tried to customize the values used by these parameters (for instance, by using a value of 256kb for maxgetobjtransferzekb setting), but with no real luck (the connection seems to abort less often but the transfer is still slowing down).
Here is an extract of the trace I get when I increase the log level in airnef.
Download history file "C:\Users\aerkis\AppData\Local\airnef\appdata\Z 50-SN6026496-downloadhist" loaded - 2 entries
Skipping DCIM - object is not file - MTP_OBJFORMAT_Assocation (0x3001)
Skipping 101NZ_50 - object is not file - MTP_OBJFORMAT_Assocation (0x3001)
>> MTP_OP_GetObject
Downloading "DSC_0490.JPG": 0%DSC_0490.JPG - downloading next piece, offset=0x0, count=0x100000
execMtpOp: MTP_OP_GetPartialObject - CmdReq payload:
0000: 06 00 00 00 01 00 00 00 - 1b 10 0b 00 00 00 ea 41 ........ - .......A
0010: 19 29 00 00 00 00 00 00 - 10 00 .)...... - ..
execMtpOp: MTP_OP_GetPartialObject - DataStart payload [expected data bytes is 0x100000]
0000: 09 00 00 00 0b 00 00 00 - 00 00 10 00 00 00 00 00 ........ - ........
0%execMtpOp: MTP_OP_GetPartialObject - Data payload [ID a] (0x00005b3c bytes):
0000: 0a 00 00 00 0b 00 00 00 - ff d8 ff e1 ff fe 45 78 ........ - ......Ex
0010: 69 66 00 00 49 49 2a 00 - 08 00 00 00 0d 00 0f 01 if..II*. - ........
0020: 02 00 12 00 00 00 ac 00 - 00 00 10 01 02 00 0b 00 ........ - ........
0030: 00 00 c0 00 00 00 12 01 - 03 00 01 00 00 00 01 00 ........ - ........
1%execMtpOp: MTP_OP_GetPartialObject - Data payload [ID a] (0x00005b3c bytes):
0000: 0a 00 00 00 0b 00 00 00 - 4f 00 72 a5 99 4e c4 fb ........ - O.r..N..
0010: f3 a3 26 61 66 1d 98 d7 - d7 98 1a 5d cc 26 ac f3 ..&af... - ...].&..
0020: f3 c4 4e 99 a5 72 00 4f - 5e 30 c2 15 12 f9 94 eb ..N..r.O - ^0......
0030: 03 dc 76 d1 ed ca 68 c7 - e7 c8 6a cd f1 d6 7c e3 ..v...h. - ..j...|.
execMtpOp: MTP_OP_GetPartialObject - Data payload [ID a] (0x00005b3c bytes):
0000: 0a 00 00 00 0b 00 00 00 - 00 00 00 00 00 00 00 00 ........ - ........
0010: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ........ - ........
0020: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ........ - ........
0030: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ........ - ........
2%execMtpOp: MTP_OP_GetPartialObject - Partial payload after error (0x00004329 bytes):
0000: 0a 00 00 00 0b 00 00 00 - 20 20 20 20 20 20 20 20 ........ -
0010: 20 20 20 20 20 20 20 20 - 20 20 20 20 20 20 20 20 -
0020: 20 20 20 20 20 20 20 20 - 20 20 20 20 20 20 20 20 -
0030: 20 20 20 20 20 20 20 20 - 20 20 20 20 20 20 20 20 -
0040: 20 20 20 20 20 20 20 20 - 20 20 20 20 20 20 20 20 -
0050: 20 20 20 20 20 20 20 20 - 20 20 20 20 20 20 20 20 -
0060: 20 20 20 20 20 20 20 20 - 20 20 20 20 20 20 20 20 -
0070: 20 20 20 20 20 20 20 20 - 20 20 20 20 20 20 20 20 -
0080: 20 20 20 20 20 20 20 20 - 20 20 20 20 20 20 20 20 -
0090: 20 20 20 20 20 20 20 20 - 20 20 20 20 20 20 20 20 -
DSC_0490.JPG - error during download, writing 0x0 bytes of buffered data
DSC_0490.JPG - writing partial payload data of 0x154bd bytes
C:\Users\aerkis\Pictures\DSC_0490.JPG writing 0x154bd bytes, closeAfterWriting=0
MTP_OP_GetPartialObject: Socket error, partial data received - 0x4321 of 0x5b34 bytes for specific payload, 0x154bd of 0x100000 of total data bytes expected. Error: timed out
Therefore, I request some help to know if it exists a way to better understand this problem and possibly correct it (maybe by configuring some parameters ?).
Any help would be greatly appreciated !
CoreData: sql:
SELECT t0.Z_ENT, t0.Z_PK, t0.Z_OPT, t0.ZCLIENTCREATEDAT, t0.ZCLIENTUPDATEDAT, t0.ZCREATEDAT, t0.ZDATERAISED, t0.ZID, t0.ZLOCKVERSION, t0.ZNAME, t0.ZSEQUENCENUMBER, t0.ZTYPE, t0.ZUPDATEDAT, t0.ZUUID, t0.ZVSYNCSTATUS, t0.ZVVERSION, t0.ZVVERSIONSTATUS, t0.ZCREATEDBY, t0.ZDATA, t0.ZOWNEDBY, t0.ZPROJECT, t0.ZPROJECTCOMPANY, t0.ZTEMPLATE, t0.ZWBSITEM, t0.ZACTIONTYPE, t0.ZSTATUS, t0.ZCOMPANY, t0.ZCLOSEDREASON, t0.ZDOCUMENTDATA, t0.ZSMARKWHENREADYTOSEND, t0.ZSPDFSYNCSTATUS, t0.ZSTATUS1, t0.ZAUTHORISATIONCODE, t0.ZBCCRECEIVED, t0.ZRECIPIENTEMAIL, t0.ZRECIPIENTNAME, t0.ZRFIRESPONSESTATUS
FROM ZBASEFORM t0
WHERE ((( t0.ZVVERSIONSTATUS = ? OR ( t0.ZVVERSIONSTATUS = ? AND t0.ZVSYNCSTATUS = ?) OR ( t0.ZVVERSIONSTATUS = ? AND t0.ZVSYNCSTATUS = ?)) AND t0.ZPROJECT = ?) AND t0.Z_ENT = ?)
ORDER BY t0.ZDATERAISED DESC, t0.ZCLIENTCREATEDAT DESC
CoreData: annotation: sql connection fetch time: 1.7336s
CoreData: annotation: total fetch execution time: 1.7462s for 1868 rows.
The table has only 1975 rows and I am fetching 1868 of them.
I copied the database from device to desktop and did sqlite> EXPLAIN SELECT ... and got this beast.
addr opcode p1 p2 p3 p4 p5 comment
---- ------------- ---- ---- ---- ------------- -- -------------
0 Init 0 105 0 00
1 SorterOpen 1 40 0 k(2,-B,-B) 00
2 OpenRead 0 8 0 37 00
3 OpenRead 2 76 0 k(2,,) 02
4 Integer 7 1 0 00
5 SeekGE 2 60 1 1 00
6 IdxGT 2 60 1 1 00
7 Seek 2 0 0 00
8 Column 0 8 2 00
9 Eq 3 16 2 (BINARY) 44
10 Ne 5 13 2 (BINARY) 54
11 Column 0 6 4 00
12 Eq 6 16 4 (BINARY) 44
13 Ne 5 59 2 (BINARY) 54
14 Column 0 6 4 00
15 Ne 7 59 4 (BINARY) 54
16 Column 0 12 4 00
17 Ne 8 59 4 (BINARY) 54
18 Column 2 0 11 00
19 IdxRowid 2 12 0 00
20 Column 0 2 13 00
21 Column 0 24 14 00
22 Column 0 25 15 00
23 Column 0 26 16 00
24 Column 0 27 17 00
25 Column 0 3 18 00
26 Column 0 4 19 00
27 Column 0 29 20 00
28 Column 0 5 21 00
29 Column 0 30 22 00
30 Column 0 28 23 00
31 Column 0 31 24 00
32 Column 0 6 25 00
33 Column 0 7 26 00
34 Column 0 8 27 00
35 Column 0 9 28 00
36 Column 0 10 29 00
37 Column 0 11 30 00
38 Column 0 12 31 00
39 Column 0 13 32 00
40 Column 0 14 33 00
41 Column 0 15 34 00
42 Column 0 32 35 00
43 Column 0 16 36 00
44 Column 0 17 37 00
45 Column 0 18 38 00
46 Column 0 36 39 00
47 Column 0 19 40 00
48 Column 0 20 41 00
49 Column 0 21 42 00
50 Column 0 33 43 00
51 Column 0 22 44 00
52 Column 0 34 45 00
53 Column 0 35 46 00
54 Column 0 23 47 00
55 Copy 17 9 0 00
56 Copy 14 10 0 00
57 MakeRecord 9 39 48 00
58 SorterInsert 1 48 0 00
59 Next 2 6 1 00
60 Close 0 0 0 00
61 Close 2 0 0 00
62 OpenPseudo 3 49 40 00
63 SorterSort 1 104 0 00
64 SorterData 1 49 3 00
65 Column 3 2 11 00
66 Column 3 3 12 00
67 Column 3 4 13 00
68 Column 3 5 14 00
69 Column 3 6 15 00
70 Column 3 7 16 00
71 Column 3 8 17 00
72 Column 3 9 18 00
73 Column 3 10 19 00
74 Column 3 11 20 00
75 Column 3 12 21 00
76 Column 3 13 22 00
77 Column 3 14 23 00
78 Column 3 15 24 00
79 Column 3 16 25 00
80 Column 3 17 26 00
81 Column 3 18 27 00
82 Column 3 19 28 00
83 Column 3 20 29 00
84 Column 3 21 30 00
85 Column 3 22 31 00
86 Column 3 23 32 00
87 Column 3 24 33 00
88 Column 3 25 34 00
89 Column 3 26 35 00
90 Column 3 27 36 00
91 Column 3 28 37 00
92 Column 3 29 38 00
93 Column 3 30 39 00
94 Column 3 31 40 00
95 Column 3 32 41 00
96 Column 3 33 42 00
97 Column 3 34 43 00
98 Column 3 35 44 00
99 Column 3 36 45 00
100 Column 3 37 46 00
101 Column 3 38 47 00
102 ResultRow 11 37 0 00
103 SorterNext 1 64 0 00
104 Halt 0 0 0 00
105 Transaction 0 0 188 0 01
106 TableLock 0 8 0 ZBASEFORM 00
107 Integer 1 3 0 00
108 Integer 2 5 0 00
109 Integer 4 6 0 00
110 Integer 5 7 0 00
111 Integer 3 8 0 00
112 Goto 0 1 0 00
I figured out the cause of the slowness.
One of the object properties was a NSData blob which apparently absolutely kills fetch sorting in CoreData. So watch out for that.
I tried to make an analogue nc (netcat) tool.
Open file and send it in to TCP socket.
client (sender) side
procedure TForm1.SpeedButton3Click(Sender: TObject);
var Client:TTCPBlockSocket;
FS: TFileStream;
begin
Client:=TTCPBlockSocket.Create;
Client.RaiseExcept:=True;
Client.Connect('192.168.1.95','9999');
FS:=TFileStream.Create('/tmp/test_print.pdf',fmOpenRead);
FS.Position:=0;
Client.SendStream(FS);
FS.Free;
Client.CloseSocket;
Client.Free;
end;
server (reciever) side
nc -l 192.168.1.95 9999 > test.pdf
After run i get test.pdf but md5sum not valid
fe2e5d86acd267ca39a9c15c456e1be0 /tmp/test_print.pdf
34d755aa81d72f525a5e691e98bed283 test.pdf
size is differ too
-rw-rw---- 1 user1 DomainUsers 46444 Июн 8 17:11 /tmp/test_print.pdf
-rw-r--r-- 1 user1 DomainUsers 46448 Июн 11 15:40 test.pdf
What i do wrong? Where is my mistake?
p.s. Excess 4 bytes at the beginning of test.pdf (6c,b5,00,00)
[user1#pandora6 /tmp]$ hexdump -C test.pdf | head -5
00000000 6c b5 00 00 25 50 44 46 2d 31 2e 34 0a 25 c7 ec |l...%PDF-1.4.%..|
00000010 8f a2 0a 34 20 30 20 6f 62 6a 0a 3c 3c 2f 4c 69 |...4 0 obj.<</Li|
00000020 6e 65 61 72 69 7a 65 64 20 31 2f 4c 20 34 36 34 |nearized 1/L 464|
00000030 34 34 2f 48 5b 20 34 33 39 36 38 20 31 34 32 5d |44/H[ 43968 142]|
00000040 2f 4f 20 36 2f 45 20 34 33 39 36 38 2f 4e 20 31 |/O 6/E 43968/N 1|
[user1#pandora6 /tmp]$ hexdump -C /tmp/test_print.pdf | head -5
00000000 25 50 44 46 2d 31 2e 34 0a 25 c7 ec 8f a2 0a 34 |%PDF-1.4.%.....4|
00000010 20 30 20 6f 62 6a 0a 3c 3c 2f 4c 69 6e 65 61 72 | 0 obj.<</Linear|
00000020 69 7a 65 64 20 31 2f 4c 20 34 36 34 34 34 2f 48 |ized 1/L 46444/H|
00000030 5b 20 34 33 39 36 38 20 31 34 32 5d 2f 4f 20 36 |[ 43968 142]/O 6|
00000040 2f 45 20 34 33 39 36 38 2f 4e 20 31 2f 54 20 34 |/E 43968/N 1/T 4|
Well... Hex 00 00 B5 6C (your extra bytes in reverse) is equal to 46444. So my guess is that TFileStream or SendStream sends the number of bytes it wants to send before the actual data.
Looking at the code of Synapse there is the function:
procedure TBlockSocket.InternalSendStream(const Stream: TStream; WithSize, Indy: boolean);
And SendStream calls it like this:
InternalSendStream(Stream, true, false);
So the WithSize is true and the size of the stream is send before the actual data.
If you use SendStreamRaw all is send without the size in front of it.
procedure TForm1.SpeedButton3Click(Sender: TObject);
var Client:TTCPBlockSocket;
FS: TFileStream;
begin
Client:=TTCPBlockSocket.Create;
Client.RaiseExcept:=True;
Client.Connect('192.168.1.95','9999');
FS:=TFileStream.Create('/tmp/test_print.pdf',fmOpenRead);
FS.Position:=0;
Client.SendStreamRAW(FS);
FS.Free;
Client.CloseSocket;
Client.Free;
end;
I am trying to convert a string to a list of integers.
String = "08 02 22 97 38 15 00 40 00 75 04 05 07 78 52 12 50 77 91 08".
But
lists:map(fun(X) -> string:to_integer(X) end, string:tokens(String, " ")).
just gives me...
[{8,[]}, {2,[]}, {22,[]}, {97,[]}, ... , {91,[]}, {8,[]}]
Can someone perhaps tell me what a good/nice way would be to get?
[8,2,22,97...91,8]
(Or do I need a helper function?)
This works:
String = "08 02 22 97 38 15 00 40 00 75 04 05 07 78 52 12 50 77 91 08".
lists:map(fun(X) -> {Int, _} = string:to_integer(X),
Int end,
string:tokens(String, " ")).
> [8,2,22,97,38,15,0,40,0,75,4,5,7,78,52,12,50,77,91,8]
See, string:to_integer returns not a single integer, but a tuple:
to_integer(String) -> {Int,Rest} | {error,Reason}
... so you have to extract the first element from this tuple to get the actual number.
Also, you might use list generator syntax:
[begin {Int,_}=string:to_integer(Token), Int end|| Token<-string:tokens(String," ")].
From shell:
1> String = "08 02 22 97 38 15 00 40 00 75 04 05 07 78 52 12 50 77 91 08".
"08 02 22 97 38 15 00 40 00 75 04 05 07 78 52 12 50 77 91 08"
2>
2> [begin {Int,_}=string:to_integer(Token), Int end|| Token<-string:tokens(String," ")].
[8,2,22,97,38,15,0,40,0,75,4,5,7,78,52,12,50,77,91,8]
[list_to_integer(X)|| X<-string:tokens(String," ")].
I'm trying to decode an AMF0 message with AMF3 included .. All is well
except making sense of the U29 format and the way string are encoded
in AMF4
channel=3 size=134 pkttype=0x11 time=1973
00000: 00 02 00 14 73 65 6E 64 55 6E 69 76 65 72 73 61 6C 4D 65 73 ....sendUniversalMes
00020: 73 61 67 65 00 00 00 00 00 00 00 00 00 05 02 00 11 6D 62 5F sage.............mb_
00040: 31 32 32 31 30 5F 37 35 39 32 33 33 38 30 05 00 40 58 C0 00 12210_75923380..#X..
00060: 00 00 00 00 11 0A 0B 01 09 68 62 69 64 04 81 CF 5E 09 73 72 .........hbid...^.sr
00080: 63 65 06 49 63 37 62 39 32 33 65 65 2D 30 61 30 38 2D 34 62 ce.Ic7b923ee-0a08-4b
00100: 61 32 2D 38 65 37 63 2D 63 38 32 61 39 33 64 37 37 31 34 32 a2-8e7c-c82a93d77142
00120: 09 68 62 64 6C 04 00 09 74 65 78 74 01 01 .hbdl...text..
first byte I skip
02 = string
00 14 = length of string ( 20 characters , sendUniversalMessage )
00 00 00 00 00 00 00 00 00 = number = 0
05 = null
02 = string
00 11 = length of string ( 17 characters , mb_12210_75923380 )
05 = null
00 40 58 C0 00 00 00 00 00 = number = 99
11 = AMV+
here is where I have problems
0A = AMF3 object
now I need to do a readU29 which starts with
0B = what does this mean
01 = what does this mean
09 = what does this mean
where is the length of the string 'hbid' ?
in U29, if the first byte is worth less than 128, it fits on the first byte. So you have to read this as 3 different u29s, worth 0B, 01, 09.
0B: details about the type of object. It seems you're not too interested in that byte and it's complicated, so pass.
01: The LSB is the bit that says that this isn't a string reference. Then 01 >> 1 = 0 is the length of the class name. This means empty string, which means this is an anonymous (untyped) object.
09: = 00001001. The LSB is also the bit that says this isn't a string reference. Then 1001 >> 1 = 0100 = 4 is the string length.
hope that helps