Develop Reference

Anylogic: printing the outputs to excel

I have some datasets which I want to print to excel after each run of simulation.
Dataset name: Arrival1,
Excel file name: ExcelOutputs,
The code that I wrote: excelOutputs.writeDataSet(this.Arrival1, "Tabelle1", 1, 1);
Data in dataset:
0 0
300 15
480 24
700 35
900 45
1,180 59
1,360 68
1,520 76
1,740 87
1,980 99
2,180 109
2,460 123
2,700 135
2,900 145
3,340 167
3,500 175
Data I get in the excel sheet:
0 0
340 17
580 29
700 35
900 45
1200 60
1420 71
1600 80
1800 90
2020 101
2200 110
2340 117
2520 126
2620 131
2820 141
3000 150
3220 161
3360 168
Totally different numbers and I don't know where they come from. There is no other dataset with these numbers and the excel sheet is initially empty.
Can someone please help me! Thank you in advance

ISO 8583 Messge -- Bitmap not getting parsed at switch end using jpos

I'm trying to build a simulator in java using jpos.
However i'm able to send values to my switch but as per switch vendor they are not receiving proper values at tcpip level due to which the conversion is failing.
Please find the below log generated at my end during sending the data before socket stream.
Request sent to server
Clear String:
0200723A4401A8E19008166070658525235400011000000000150000020110150412345
61300000201020160119010680019206900000376070658525235400=24075203640000000000
428313349275RGB12345RGB12345 NPCI R-TECH GOREGAON(E)MUMBAI MHIN
022051005ATM010580050099935698BC03BEBAD073D9021121412220033000400085
Message Length : 291
Sent Hex Dump:
0000 30 32 30 30 37 32 33 41 34 34 30 31 41 38 45 31 0200723A4401A8E1
0010 39 30 30 38 31 36 36 30 37 30 36 35 38 35 32 35 9008166070658525
0020 32 33 35 34 30 30 30 31 31 30 30 30 30 30 30 30 2354000110000000
0030 30 30 31 35 30 30 30 30 30 32 30 31 31 30 31 35 0015000002011015
0040 30 34 31 32 33 34 35 36 31 33 30 30 30 30 30 32 0412345613000002
0050 30 31 30 32 30 31 36 30 31 31 39 30 31 30 36 38 0102016011901068
0060 30 30 31 39 32 30 36 39 30 30 30 30 30 33 37 36 0019206900000376
0070 30 37 30 36 35 38 35 32 35 32 33 35 34 30 30 3D 070658525235400=
0080 32 34 30 37 35 32 30 33 36 34 30 30 30 30 30 30 2407520364000000
0090 30 30 30 30 34 32 38 33 31 33 33 34 39 32 37 35 0000428313349275
00a0 52 47 42 31 32 33 34 35 52 47 42 31 32 33 34 35 RGB12345RGB12345
00b0 20 20 20 20 20 20 20 4E 50 43 49 20 52 2D 54 45 NPCI R-TE
00c0 43 48 20 47 4F 52 45 47 41 4F 4E 28 45 29 4D 55 CH GOREGAON(E)MU
00d0 4D 42 41 49 20 20 20 20 20 20 20 4D 48 49 4E 30 MBAI MHIN0
00e0 32 32 30 35 31 30 30 35 41 54 4D 30 31 30 35 38 22051005ATM01058
00f0 30 30 35 30 30 39 39 39 33 35 36 39 38 42 43 30 0050099935698BC0
0100 33 42 45 42 41 44 30 37 33 44 39 30 32 31 31 32 3BEBAD073D902112
0110 31 34 31 32 32 32 30 30 33 33 30 30 30 34 30 30 1412220033000400
0120 30 38 35 085
As per my switch vendor they should receive the value of bitmap in proper sequence and not as a HEX Value.
Please find the below sample line given by my switch vendor.
0000 30 32 30 30 72 3A 44 01 A8 E1 0200r:D¨á <--
Can any one please assist on this regards.
Please find my below code:
GenericPackager packager = new GenericPackager("basic.xml");
// Create ISO Message
ISOMsg isoMsg = new ISOMsg();
isoMsg.setPackager(packager);
isoMsg.setMTI("0200");
isoMsg.set(2, "6070658525235400");
isoMsg.set(3, "11000");
isoMsg.set(4, "000000150000");
isoMsg.set(7, "0201101504");
isoMsg.set(11, "123456");
isoMsg.set(12, "130000");
isoMsg.set(13, "0201" );
isoMsg.set(15, "0201");
isoMsg.set(18, "6011");
isoMsg.set(22, "901");
// isoMsg.set(25, "00");
isoMsg.set(32, "800192");
isoMsg.set(33, "900000");
isoMsg.set(35, "6070658525235400=24075203640000000000");
isoMsg.set(37, "428313349275");
isoMsg.set(41 , "RGB12345");
isoMsg.set(42 , "RGB12345 ");
isoMsg.set(43 , "NPCI R-TECH GOREGAON(E)MUMBAI MHIN");
isoMsg.set(48 , "051005ATM0105800500999");
isoMsg.set(49 , "356");
isoMsg.set(52 , "98BC03BEBAD073D9");
isoMsg.set(61 , "121412220033000400085");
// print the DE list
logISOMsg(isoMsg);
byte[] send_PackedRequestData = isoMsg.pack();
:
:
outStream = new BufferedOutputStream(connection.getOutputStream());
outStream.write(send_PackedRequestData);
outStream.flush();

This question is flawed, it's not possible to help without studying the specs.
In addition, I hope the card you show there is a test card, otherwise, please notify the issuer to block it.
That said, you're probably using IFA_BITMAP instead of IFB_BITMAP, but that change will just solve your bitmap generation, you probably have many other fields badly configured.

Java SSL Streaming - splitted applicationdata

I try to send a byte[] () over a established SSL Connection (handshake etc is done).
The result: The byte[] is spitted into two packets (see debug below):
First packet: just the first byte of the application data (**01**) .
Second packet: the rest (fe db 01 00 ...) 650 Bytes
Is there a way to commit all application data bytes in one packet?
Stream to send 651 Bytes:
**01** fe db 01 00 00 02 83 3c 3f 78 6d 6c 20 76 65 72 73 69 6f 6e 3d 22 31 2e 30 22 20 65 6e 63 6f 64 69 6e 67 3d 22 75 73 2d 61 73 63 69 69 22 20 73 74 61 6e 64 61 6c 6f 6e 65 3d 22 6e 6f 22 3f 3e …
javax.net.debug output
Padded plaintext before ENCRYPTION: len = 32
0000: **01** 06 03 06 46 7F 7F AE D4 E8 30 5D B7 DB 3C 44 ....F.....0]..<D
0010: 02 08 C9 2A A1 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A ...*............
1, WRITE: TLSv1 Application Data, length = 32
[Raw write]: length = 37
0000: 17 03 01 00 20 B3 4E EE CE 5B 69 EC A5 4A 80 7F .... .N..[i..J..
0010: D6 03 35 AF 6A 7B 85 17 B7 46 A2 31 B2 EF 7E D0 ..5.j....F.1....
0020: EA 1B 67 7E ED ..g..
Padded plaintext before ENCRYPTION: len = 672
0000: FE DB 01 00 00 02 83 3C 3F 78 6D 6C 20 76 65 72 .......<?xml ver
0010: 73 69 6F 6E 3D 22 31 2E 30 22 20 65 6E 63 6F 64 sion="1.0" encod
0020: 69 6E 67 3D 22 75 73 2D 61 73 63 69 69 22 20 73 ing="us-ascii" s
0030: 74 61 6E 64 61 6C 6F 6E 65 3D 22 6E 6F 22 3F 3E tandalone="no"?>
[…]

Sun's impl comments:
By default, we counter chosen plaintext issues on CBC mode
ciphersuites in SSLv3/TLS1.0 by sending one byte of application
data in the first record of every payload, and the rest in
subsequent record(s). Note that the issues have been solved in
TLS 1.1 or later.
Experiment with SSLEngine.wrap( largePlainText ) shows that it produces 2 SSL records, the 1st record contains 1 byte of plain text, the 2nd record contains 15846 bytes of plain text.
The receiver API probably handle record-by-record, so it'll return 1 byte for the 1st read.
We can also observe this behavior in other SSL impls, e.g. HTTPS requests from web browsers.
OpenSSL inserts empty records against the attack. If the receiver is Java SSL socket, the input stream cannot return 0 bytes for read(), so the record is skipped. Other receivers may not be prepared for a 0-length record and may break.

The assumption you're making about reading the byte[] exactly as you write them on the other end is a classic TCP mistake. It's not actually specific to SSL/TLS, but could also happen with a TCP connection.
There is no guarantee in TCP (and in SSL/TLS) that the reader's buffer will be filled with the exact same packet length as the packets in the writer's buffer. All TCP guarantees is in-order delivery, so you'll eventually get all your data, but you have to treat it as a stream.
This is why protocols that use TCP rely on indicators and delimiters to tell the other end when to stop reading certain messages.
For example, HTTP 1.1 uses a blank line to indicate when the headers end, and it uses the Content-Length header to tell the recipient what entity length to expect (or chunked transfer encoding). SMTP also uses line returns and . at the end of a message.
If you're designing your own protocol, you need to define a way for the recipient to know when what you define as meaningful units of data are delimited. When you read the data, read such indicators, and fill in your read buffer until you get the amount of bytes you expect or until you find the delimiter that you've defined.

I had the same problem until I saw this page:
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7157903
So, I run the JVM with -Djsse.enableCBCProtection=false parameter and now the data is not splitted.
Best regards

How to detect Java string inside a .so file?

I'm recompiling a Java program, and I have the following method:
public static native String getMyString(String s);
getMyString is implemented inside mylibrary.so, and looks like follows:
; Scrambler::getMyString(char const*)
EXPORT _ZN9Scrambler18getMyStringEPKc
_ZN9Scrambler18getMyStringEPKc
LDR R1, =(mystring - 0x14FC8)
PUSH {R4-R6,LR}
ADD R1, PC ; "mystring"
MOV R4, R0
BLX strcasecmp
CMP R0, #0
BNE.W loc_150FC
which than ends up in
LDR R5, =(unk_6AE24 - 0x14FD8)
ADD R5, PC
The R5 seems to be the return value here.
The unk_6AE24 looks like follows:
27
68 5D 6D 06 3F 10 6D 26 32 10 56 12 06 3F 32 5D
12 27 26 4B 0D 5D 27 4B 6E 0D 2B 06 32 5D 68 24
3F 32 06 24 70 56 00 63 69 4C 1D 06 5A 7F 0C 34
1E 67 3B 63 32 5F 16 1D 34 5F 1E 32 42 69 18 49
3F 51 49 0C 1F 0C 0E 77 2F 44 69 7F 5A 0C 0B 34
0C 34 1C 24 32 5F 7F 00 00 00 00 1D 30 3B 5F 30
IDA suggests, that the string in question is 27 68 5D 6D or "'h]m", but I'm having my doubts. When I was using c++ ages ago, the strings used to end with 0, which would make for return value of 27 68 5D 6D 06 3F 10 6D 26 32 10 56 12 06 3F 32 5D 12 27 26 4B 0D 5D 27 4B 6E 0D 2B 06 32 5D 68 24 3F 32 06 24 70 56 . Or we could be talking about java string, which may have its own format.
What kind of string will getMyString return?

What kind of string will getMyString return?
It will return a java.lang.String, you can get that from the declaration.
The actual character data will (probably) be one redirection away from that. (a String is probably a pointer to a char array and a size). Keep in mind that in Java, a char is 16 bits.
What are you trying to do, anyway? Much easier to just set a breakpoint right after getMyString returns and look at the return value in a debugger.

Why might RvdProxy.getServices() incorrectly return an empty Array?

The following code snippet attempts to create a Tib DaemonManager connecting to a particular rvd, and then query for that rvd's services.
public static void main(String[] args) throws RuntimeException {
DaemonManager daemonManager = new DaemonManager("http://foo.com:7580");
if(daemonManager.getDaemonType() == DaemonManager.RVD) {
DaemonProxy daemonProxy = daemonManager.getDaemonProxy();
final RvdProxy rvdProxy = (RvdProxy) daemonProxy;
Service[] services = rvdProxy.getServices();
System.out.println(services.length); //prints 0
for (Service service : services) {
System.out.println(service.getNetwork());
}
}
}
This prints zero, even though the web interface for this rvd lists multiple available services. Why might this happen?
The daemon I am connecting to is running v 7.5.1 of the software, and the rvconfig.jar that I am using is from v 7.5.1 as well.
Is there a gotcha when using Tibco's DaemonManager that is causing me to come unstuck?

I used Wireshark to look at the traffic being sent between my RvdProxy and the RVD itself, and it looks like a lot of HTTP GET traffic. For example:
0000 00 1e 0b a4 d1 7c 00 12 d9 7c 8a bf 08 00 45 00 .....|.. .|....E.
0010 03 87 a4 58 40 00 3d 06 66 90 0a 09 14 15 0a 0a ...X#.=. f.......
0020 07 61 1d 9c bf 09 fe 1e d6 82 6e 77 b9 52 80 18 .a...... ..nw.R..
0030 00 1b 05 43 00 00 01 01 08 0a ac 1c 6f 67 07 b2 ...C.... ....og..
0040 86 1f 72 3d 23 30 30 38 30 38 30 3e 3c 66 6f 6e ..r=#008 080><fon
0050 74 20 66 61 63 65 3d 48 65 6c 76 65 74 69 63 61 t face=H elvetica
0060 2c 41 72 69 61 6c 20 73 69 7a 65 3d 32 20 63 6f ,Arial s ize=2 co
0070 6c 6f 72 3d 23 46 46 46 46 46 46 3e 3c 62 3e 43 lor=#FFF FFF><b>C
Sure enough, upon further inspection, it turns out that the requests being made by the proxy are to the web pages served by the Daemon itself - so the proxy API is just a screen-scraper.
But why am I getting no services if they appear on the web pages that are being screen-scraped?
Switch on debugging:
System.setProperty("com.tibco.tibrv.config.debug","classes-to-debug")
And you find that the pattern being used to extract the services from the web-page...
/services,GET~~~~~\
service_detail\\?(\\d+)>\\1</a>.*?size=2>(\\d+\\.\\d+\\.\\d+\\.\\d+)</td>.*?size=2>
(\\d+)</td>.*?size=2>(\\d+)</td>~~~~~\
...fails to match anything! In my case it is because my service networks are not of the form (\\d+\\.\\d+\\.\\d+\\.\\d+) but rather of the form ;(\\d+\\.\\d+\\.\\d+\\.\\d+) - note the leading semicolon. This subtle difference is the source of all of my problems!
This looks like a bug in the rvconfig jar - which needs to be raised with Tibco! :(