APDU buffer access

Let’s say that I want to define the method that handles the command APDU that is located in the APDU buffer.
I do not want for the method to have input parameter equals APDU. Instead I want the method to be without any input parameter. The method itself must be able to read the APDU buffer. Is it possible and if yes how? I saw the BACAccelerator class that has that kind of definition that suits me:
      * Unwraps (verify and decrypt) the command APDU located in the APDU buffer.
      * The command buffer has to be filled by the APDU.setIncomingAndReceive()
      * method beforehand. The verified and decrypted command data get placed at
      * the start of the APDU buffer.
     public short unwrapAPDU() throws BACAcceleratorException {
          return ((short) 0);
     }

there is probably an application specific buffer that the APDU is copied into. This may be a field of the class that is accessed. This is just a guess though.
Cheers,
Shane

Similar Messages

  • Decoupled Infotype - Correct Buffer Access for PA30 and from BAPI?

    Weu2019ve created a custom decoupled infotype and read/delete/update/insert work just fine with PA30, but the same methods supplied with the corresponding Check class do not work when called from a program.  The Check class inherits from CL_HRPA_INFOTYPE_NNNN.  After going through some documentation, we made the Check class inherit from CL_HRPA_INFTY_NNNN and now the modify method works if we redefine the modify method to use the direct buffer update methods from IF_HRPA_MASTERDATA_BUFFER (implementation in CL_HRPA_MASTERDATA_BUFFER). But then, PA30 stops working and throws an exception - u201CInfotype does not support legacy accessu201D.
    Anyone know why the SAP generated infotype check class methods not work when called as it is? There are no error messages thrown and no messages returned in the message handler too. Just that the database does not get updated. The Read method always works for all cases though. Help documentation is clear about the risks and differences between the two buffer access methods but issues exist when using PA30 and when trying to access/update the buffer from a program or BAPI.

    Since you are adopting an approach per [SAP help|http://help.sap.com/saphelp_erp2005/helpdata/en/43/21d2254bba2bebe10000000a1553f7/frameset.htm], I guess only SAP can help. May be you should try your luck by opening a Customer message (i.e. if you haven't already done so).
    ~Suresh

  • Apdu buffer

    Hi,
    I am concerning how i should create APDU buffer array. I wonder if i should use native code to create (through native method t0InitAPDUBuffer()) or use Java with simple statment:
    buffer = new byte[261];I know it depends on JCRE implementer, but i would like to discuss with you the pros and cons of each solution.
    In my point of view, using native method will gain speed because we are creating a big array. And this is the only reason for using native method to do this task.
    Is it really really slow to create an array of 261 elements using java?
    thanks,
    Hoang Long

    Hi,
    Mehmet wrote:
    Can you please give some more clue about how to initialize APDU on the computer code? It will be a BIG help for me!You should start a new thread and reference this one if necessary. Also, you question is a little unclear. In the new thread you should explain what you are trying to achieve, what you have tried already and what the issue you are having is.
    Cheers,
    Shane

  • Sending a byte array of greater length than the APDU data buffer

    Hello again, I am now trying to send a byte array of length 480 from the smart card. I've tried setting the outgoing length to 480 first but as i had expected, this threw an exception. Then i tried setting it to 240 and then copying from the array into the apdu buffer in two halves and calling sendBytes() twice, but this only worked the first time - it send the first 240 bytes and then threw an error. Is it possible to do what i am trying to accomplish? If so, what am I missing?

    the applet:
    H:\java_card_kit-2_2_1-win-dom\java_card_kit-2_2_1\samples\src\com\sun\javacard\samples\photocard
    the client:
    H:\java_card_kit-2_2_1-win-dom\java_card_kit-2_2_1\samples\src_client\com\sun\javacard\clientsamples\photocardclient
    here is the code i have used to store large data on card. maybe it will help you.
    i send a series of apdu, where each contains 128 bytes of data (all apdu must have the same length - except the last).
    public void writeAPDU(APDU apdu)
         byte[] buffer = apdu.getBuffer();
         short lc = (short)(buffer[ISO7816.OFFSET_LC]&0xFF);          
         short p1 = (short)(buffer[ISO7816.OFFSET_P1]&0xFF); // counter
         short p2 = (short)(buffer[ISO7816.OFFSET_P2]&0xFF); // length of send data
         short offset = (short)(p1 * p2); // calculate the offset
         apdu.setIncomingAndReceive();
         // check for first apdu (contains the total size of data)
         if(p1 == 0 && p2 == 0)
              short l = Util.getShort(buffer,ISO7816.OFFSET_CDATA);
              data = new byte[l];
         else
              // store bytes in array
              Util.arrayCopy(buffer, ISO7816.OFFSET_CDATA, data, offset, lc);
    }

  • Problem in APDU-case 1:No command,no response

    Hello evrybody.I have done a method in my java card applet which does not return any command data neither response data.
    I wrote in my APDU script the following(as defined the case 1 in the Zhiqun Chen's book-page 102,says that "P3(the 5th field in the APDU buffer) has to be 0"):
    //CLA INS P1 P2 P3
    0xB1 0x50 0x00 0x00 0x00;
    Howevr, the executed APDU script returns me the following:
    com.sun.javacard.apdutool.ReaderWriterError: Encountered ";" at line 105, column
    25.
    Was expecting one of: <INTEGER_LITERAL> ...
    <CHARACTER_LITERAL> ...
    <STRING_LITERAL> ...
    I have tried to add another 0x00 byte at the end of the above script line, as follwoing:
    //CLA INS P1 P2 Lc Le
    0xB1 0x50 0x00 0x00 0x00 0x00;
    //WIth the idea that Lc=0(no command data) and Le=0(no response data)
    I noticed that the method is working properly(does the work that has to do;I tested and I am definetely sure) but on the other hand the executed APDU script returns as SW1 SW2 the following:
    CLA: b1, INS: 50, P1: 00, P2: 00, Lc: 00, Le: 00, SW1: 6f, SW2: 00 (!!!!)
    Actually,I was waiting for SW1 SW2 == 90 00.
    I do not know why this is returned.
    Do you know what it is going wrong?
    I will appreciate any help and guidance.
    Thank you for you time.

    I will give the code of my function.I think the problem is in the code of this method(function).I will give you in order to have a look at it:
    private void delete_all_records(APDU apdu)
         ver_pin();
         byte[] buffer=apdu.getBuffer();
         byte get_P1=buffer[ISO7816.OFFSET_P1];
         byte P3=buffer[ISO7816.OFFSET_LC];
         //Check the appropriate syntax
         if (get_P1!=(byte)0) // || (P3!=(byte)0) )
         ISOException.throwIt (SW_SYNTAX_DEL_ERROR);
    // else
         //Delete all the record.This for loop
         //deletes all the records' ids.
         for (short i=0;i<kostas.length;i++)
         kostas[(short)i].record_id=(byte)0;
    I did not use any of the functions such as sendBytes() or apdu.setIncomingAndReceive because I did not want to take data either to return response data.Do you have any idea what's going on?
    I will really apprecitae any help.Thank you for your time.

  • What is th optimal Database Buffer size?

    Good evening SAP/Oracle experts,
    I am interested to know how many of you have chosen to size your Oracle data buffer (db_cache_size). There seems to be two trains of thought about this
    - one that says size the data buffer as large as you can because buffer accesses are 1000s of times quicker than disk accesses
    - another that says that "excessive buffer visits are the morbid obesity of the database. Extra logical I/O can degrade the perfromance of virtually every subsystem in an Oracle application" (quote Cary Millsap)
    As I tend to prefer the second argument, I originally sized the data buffer on our ECC5 Production system (with CI/DB running on a server with 8Gb RAM) at 500Mb. A few months after go-live, I increased the buffer to 750Mb and recently I increased it again to 1Gb. I found a slight performance improvement with each increase, but database time remained at around 50% of total response time (from ST03N) throughout. Our average response time is currently around 700-750ms, with database time around 300-400ms. Our database is currently around 450Gb.
    I therefore ask you, the SDN community, to tell me how large you tend to size your data buffer in comparison to the total amount of RAM on your database server, and what % of your average response time is spent down at the database.
    Thanks in advance for any help you can provide.
    Arwel Owen
    SAP Infrastructure Manager,
    Princes Ltd.

    Dear Arwel.
    To specify an optimal cache value, you can use the dynamic
      DB_CACHE_ADVICE parameter with statistics gathering enabled to predict
      behavior with different cache sizes through the V$DB_CACHE_ADVICE performance  view.
    When configuring a new instance, it is impossible to know the correct size for the buffer cache. Typically, a database administrator makes a first estimate for the cache size, then runs a representative workload on the instance and examines the relevant statistics to see whether the cache is under or over configured.
    For more details about Sizing the Buffer Cache and Increasing Memory Allocated to the Buffer Cachelook at oracle documentation.
    http://download-east.oracle.com/docs/cd/B10501_01/server.920/a96533/memory.htm#30301
    In General Dont waste RAM use it completely but minimum 20% to OS and the rest to allocate.
    Regards
    Vinod

  • How to generate the APDU packege in JCOP3.1 Shell (Eclipse 3.1).

    I can run the counter applete sample in JCOP3.1simulator (Eclpse 3.1) , After I selected my applet . I want to send a APDU to applet for test by JCOP Shell. But JCOP Shell always prompt the error message. for example : I want to get the counter value of the counter from applet. I use 8004000002, CLA=80 INT=04(from source code) P1=P2=00, Le=02(return short),No data Field ,no Lc; but it failed, JCOP error message:
    cm> send 8004000002
    => 80 04 00 00 02 .....
    (521016 nsec)
    <= 69 85 i.
    Status: Conditions of use not satisfied
    Any suggestion and help highly appreciated! thxs at first!
    CounterApplet code:
    public class CounterApplet extends Applet {
         private short value;
         public static void install(byte[] bArray, short bOffset, byte bLength){
              (new CounterApplet()).register(bArray, (short)(bOffset + 1), bArray[bOffset]);
         public void process(APDU apdu){
              byte[] buf = apdu.getBuffer();
              if (selectingApplet())
                   return;        
              switch(buf[ISO7816.OFFSET_INS]){
                   case (byte)0x02:
                        // set the counter to the value given in the APDU buffer
                        if (apdu.setIncomingAndReceive() != (short) 2){
                             ISOException.throwIt(ISO7816.SW_WRONG_LENGTH);
                        this.value = Util.getShort(buf, ISO7816.OFFSET_CDATA);
                        return;
                   case (byte)0x04:
                        // return the value of the counter
                        if (apdu.setIncomingAndReceive() != (short) 0){
                             ISOException.throwIt(ISO7816.SW_WRONG_LENGTH);
                        Util.setShort(buf, (short) 0, this.value);
                        apdu.setOutgoingAndSend((short) 0, (short) 2);
                        return;
                   case (byte)0x06:
                        // increment counter
                        if (apdu.setIncomingAndReceive() != (short) 0){
                             ISOException.throwIt(ISO7816.SW_WRONG_LENGTH);
                        ++this.value;
                        return;
                   case (byte)0x08:
                        // decrement counter
                        if (apdu.setIncomingAndReceive() != (short) 0){
                             ISOException.throwIt(ISO7816.SW_WRONG_LENGTH);
                        --this.value;
                        return;         
                   default:
    }

    Thanks a lot for your quick response. but I do select the applet before send the APDU .Pls read the following message. I guess whether the APDU is not correct. or JCOP3.1 is different JCOP3.0.?
    package id: |calvinpack
    applet id: | calvinapp
    cm> select |calvinpack|cavlinapp
    => 00 A4 04 00 08 A0 00 00 00 03 00 00 00 00 ..............
    (586667 nsec)
    <= 6F 10 84 08 A0 00 00 00 03 00 00 00 A5 04 9F 65 o..............e
    01 FF 90 00 ....
    Status: No Error
    cm> send 8004000002
    => 80 04 00 00 02 .....
    (442793 nsec)
    <= 69 85 i.
    Status: Conditions of use not satisfied

  • Read Mp3 from buffer with http connection in realtime?

    Hello friends, i am new in this place and my grammar and english languaje is bad.
    I wanna read mp3 from http in realtime (j2me) , without waiting for download complete file and using buffer realtime, please i need your help.
    i found in the network forum a code that maybe but I failed to make it work.
    mi mail is [email protected]
    very grateful to you.
    Edited by: chocote on May 2, 2009 12:26 AM

    Hi Andrey,
    even with access to the delta buffer it would be hard (I think impossible) to implement a new lines check.
    1. You would need the data the query has read, possibly by reading again the data the query has read (vial plan buffer access). This is in general not possible since the query has much more filtering featues compared to the plan buffer (e.g. restricted key figures).
    2. You would need a delta buffer access (but this is not exposed via an 'external API'), but this is not enough since the delta buffer does not care whether a record is new or old. One does not know this in the delta buffer.
    To implement a real new line check (only 'real' new lines are allowed) one needs the old result set; this is not even known to the OLAP since e.g. for drill-down only the needed data will be read, not the full grid the end user sees in the front end. In the 7.0 code line this information is simply not there.
    With the new infrastructure shipped in 7.01, SP05 (cf. note 1358614) a kind of new lines check in the above sense would be relatively easy (for SAP) to implement. But one question is, what is a new line, think of zero suppression, conditions ? Should the system take records into account filtered out by the above featues ? Should a new line check by a query property ?
    Regards,
    Gregor

  • Exchanging APDU's with selected applet fails

    Hi all,
    1. I developed a cardlet( normal, sample one) using JCOP
    2. Installed, selected and excanged APDU's with this applet ( on Nokia 6212,6131 and JCOP cards)
    3. Now i tried it on a SE of SIM. In this case, installation and selection succeeds but exchanging APDU's with selected applet is partial. by 'partial' what i mean is:
    i am using 0x90 as CLA byte for personalisation (now i am not checking the CLA byte from cardelt code)
    private static final byte STORE=0x01;
    private static final byte GET=0x02; , and these are INS values for getting and storing personalisation data.
    if i send STORE command like */send 90010000084142434445464748* (8 data bytes ), only first 5 bytes are being transferred to applet (i tested this fact by returning the buffer(apdu.getBuffer()) length from process(APDU apdu) function ), not the actual data. ie, only CLA, INS, P1, P2, and LC fields are being transferred to applet. so, currently the actual personlisation data is not been transferred to selected applet.
    Is there any specific data format that has to be send to a selected applet ?
    or
    In which point i am going wrong ?
    This is the cardlet code i'm using
    import javacard.framework.APDU;
    import javacard.framework.ISO7816;
    import javacard.framework.Applet;
    import javacard.framework.ISOException;
    import javacard.framework.Util;
    public class TestCard extends Applet
        private static final byte STORE=0x01;
        private static final byte GET=0x02;
        private static byte personalized=0x00;
        private static byte[] value=null;
       // private static byte testByte;
        public static void install(byte[] bArray, short bOffset, byte bLength)
            // GP-compliant JavaCard applet registration
            new TestCard().register(bArray, (short) (bOffset + 1), bArray[bOffset]);
        public void process(APDU apdu)
            // Good practice: Return 9000 on SELECT
            if (selectingApplet())
                return;
            byte[] buf = apdu.getBuffer();
            switch (buf[ISO7816.OFFSET_INS])
                case STORE:
                    value=new byte[buf[ISO7816.OFFSET_LC]];
                    //testByte=(byte)buf.length;
                    Util.arrayCopy(buf, (short)(ISO7816.OFFSET_LC+1), value, (short)0, buf[ISO7816.OFFSET_LC]);
                    personalized=(byte)0x01;
                    break;
                case GET:
                    if(personalized==0x00)
                        ISOException.throwIt((short)0x6999);
                        break;
                    //value=new byte[]{testByte};
                    apdu.setOutgoing();
                    apdu.setOutgoingLength((short)value.length);
                    apdu.sendBytesLong(value, (short)0, (short)value.length);
                    break;
                default:
                    // good practice: If you don't know the INStruction, say so:
                    ISOException.throwIt(ISO7816.SW_INS_NOT_SUPPORTED);
    }and this is the JCOP script i'm using
    /echo Opening terminal
    /terminal "winscard:4|OMNIKEY CardMan 5x21-CL 0"
    /echo Resets card
    /atr
    /echo Selecting TestCard Applet
    /select 11223344556600
    /echo Sending 8-byte Personalisation data ABCDEFGH (4142434445464748)
    /send 90010000084142434445464748
    /echo Reading personalised data
    /send 90020000and the output trace is
    /echo Opening terminal
    Opening terminal
    /terminal "winscard:4|OMNIKEY CardMan 5x21-CL 0"
    --Opening terminal
    /echo Resets card
    Resets card
    /atr
    --Waiting for card...
    ATR=3B 88 80 01 01 02 03 04 00 81 C0 00 4C             ;...........L
    /echo Selecting TestCard Applet
    Selecting TestCard Applet
    /select 11223344556600
    => 00 A4 04 00 07 11 22 33 44 55 66 00 00             ......"3DUf..
    (84234 usec)
    <= 90 00                                              ..
    Status: No Error
    /echo Sending 8-byte Personalisation data ABCDEFGH (4142434445464748)
    Sending 8-byte Personalisation data ABCDEFGH (4142434445464748)
    /send 90010000084142434445464748
    => 90 01 00 00 08 41 42 43 44 45 46 47 48             .....ABCDEFGH
    (168449 usec)
    <= 90 00                                              ..
    Status: No Error
    /echo Reading personalised data
    Reading personalised data
    /send 90020000
    => 90 02 00 00                                        ....
    (22838 usec)
    <= 00 00 00 00 00 00 00 00 90 00                      ."3DUf.... // here not getting the actual needed data.
    Status: No ErrorThanks and regards
    Sunil

    Hi all,
    after lot of trial and error and research, i found that in the above code, i am not using
    apdu.setIncomingAndReceive();this is where the problem lies. i set incoming mode after reading the apdu buffer and the problem solved.
    thanks and regards
    sunil

  • Apdu command length

    Hi
    I want to get the length of the entire command in my applet.
    I want to know "5" for the following example.
    /send 8084000000
    Is there such API?

    a command parser in process method can be something like that:
    byte MY_CLA = (byte)0x80;
    byte MY_INS = (byte)0x84;
    // get the APDU buffer bytes (get header first)
    byte[] apduBuffer = apdu.getBuffer();
    // Checking CLA values
    switch(apduBuffer[ISO7816.OFFSET_CLA]){
      case MY_CLA:
        // For a given CLA value, checking INS values
        switch(apduBuffer[ISO7816.OFFSET_INS]){
          case MY_INS:
            // For a given INS value, checking P1, P2, P3 for example:
            if((apduBuffer[ISO7816.OFFSET_P1] != (byte)0x00) || (apduBuffer[ISO7816.OFFSET_P2] != (byte)0x00))
               ISOException.throwIt(ISO7816.SW_INCORRECT_P1P2);
            if(apduBuffer[ISO7816.OFFSET_LC] != (byte)0x08)
               ISOException.throwIt(ISO7816.SW_WRONG_LENGTH);
            // After the command format checking, i can continue the processing that my command is supposed to do
          break;
          default:
            // Throw iso exception: bad instruction byte value
            ISOException.throwIt(ISO7816.SW_INS_NOT_SUPPORTED);
          break;
      break;
      default:
        // Throw iso exception: bad class byte value
        ISOException.throwIt(ISO7816.SW_CLA_NOT_SUPPORTED);
      break;
    }This example is for a case 3 apdu command.
    If your command is a case 2, you will need to get Le by invoking setOutgoing() method and checking the expected value of Le.
    Thomas
    http://jaccal.sourceforge.net/

  • How to make apdu.getBuffer() return buf that is greater than 133 bytes.

        public void process(APDU apdu) {
          byte[] buf = new byte[256];
            buf = apdu.getBuffer();
            // GOOD PRACTICE: RETURN 9000 ON SELECT
            if (selectingApplet()) {
                return;
            apdu.setIncomingAndReceive();
            switch (buf[ISO7816.OFFSET_INS]) {
                case (byte) 0x01:
    This is my process method. I have a command APDU of length 200 bytes that I want the buffer to read and store into a local byte array. However, apdu.getBuffer() is only grabbing the first 133 bytes of data.
    According to javadocs:
    "The APDU object is owned by the Java Card runtime environment. The APDU class maintains a byte array buffer which is used to transfer incoming APDU header and data bytes as well as outgoing data. The buffer length must be at least 133 bytes ( 5 bytes of header and 128 bytes of data ). The Java Card runtime environment must zero out the APDU buffer before each new message received from the CAD."
    Since the buffer length is larger than 133 bytes, why does it not accept the remaining bytes?
    I am using jCardSim on NetBeans IDE, java card version 2.2.2.
    Also, could someone explain to me what exactly apdu.setIncomingAndReceive() does? My code is able to build/run both with and without it.
    Thanks

    I tried using that in my code, but it's still not working, I must be placing it in the wrong spot. I put it in the process method right before my switch cases. Do I actually put all of the code in the while loop? Perhaps you could explain the code to me, why do you only want the last two bytes of LC, and why 55? This is what it looks like currently:
        public void process(APDU apdu) {
            byte[] buf = apdu.getBuffer();
            // GOOD PRACTICE: RETURN 9000 ON SELECT
            if (selectingApplet()) {
                return;
           short bytesLeft = (short) (buf[ISO7816.OFFSET_LC] & 0x00FF);
            if (bytesLeft < (short) 55) {
                ISOException.throwIt(ISO7816.SW_WRONG_LENGTH);
            short readCount = apdu.setIncomingAndReceive();
            while (bytesLeft > 0) {
                // process bytes in buffer[5] to buffer[readCount+4]; 
                bytesLeft -= readCount;
                readCount = apdu.receiveBytes(ISO7816.OFFSET_CDATA);
            // HARDCODED PARAMETERS TO PASS INTO FUNCTIONS
            byte[] O = new byte[6];
            byte[] U = new byte[3];
            byte[] N = new byte[5];
            byte[] A = new byte[4];
            Util.arrayCopy(buf, (short) (ISO7816.OFFSET_EXT_CDATA), O, (short) 0, (short) 6);
            Util.arrayCopy(buf, (short) (ISO7816.OFFSET_EXT_CDATA + 7), U, (short) 0, (short) 3);
            Util.arrayCopy(buf, (short) (ISO7816.OFFSET_EXT_CDATA + 11), N, (short) 0, (short) 5);
            Util.arrayCopy(buf, (short) (ISO7816.OFFSET_EXT_CDATA + 17), A, (short) 0, (short) 4);
            switch (buf[ISO7816.OFFSET_INS]) {
                case (byte) 0x01:
                    // CALL FUNCTION  R
                    byte[] b = R(O, U, N, A);
                    // PRINT B
                    apdu.setOutgoing();
                    apdu.setOutgoingLength((short) b.length);
                    apdu.sendBytesLong(b, (short) 0, (short) b.length);
                    break;
                case (byte) 0x02:
                    byte[] k2 = new byte[(short) 176];  
                    //29 is the offset in the command apdu that contains the parameter data
                   // THIS IS THE LINE THAT THE CODE FAILS AT - SINCE IT CAN ONLY READ 133 BYTES OF DATA, IT CAN'T ARRAY COPY 176 BYTES OF DATA FROM buf
                    Util.arrayCopy(buf, (short) 29, k2, (short) 0, (short) 176);
                    byte[] a = S(k2, O, U, N);
                    // PRINT a
                    apdu.setOutgoing();
                    apdu.setOutgoingLength((short) a.length);
                    apdu.sendBytesLong(a, (short) 0, (short) a.length);
                    break;

  • For which tables we allowed buffer

    hi gurus
    plz inform me
    for which tables we allowed buffer
    thank you
    kals.

    Hi
    <b>Table buffering</b>
    Advantages of buffering
    Concept of buffering
    Buffering types
    Buffer synchronization
    <b>Database access using Buffer concept</b>
    Buffering allows you to access data quicker by letting you
    access it from the application server instead of the database.
    <b>Advantages of buffering</b>
    Table buffering increases the performance when the records of the table are read.
    As records of a buffered table are read directly from the local buffer of the application server on which the accessing transaction is running, time required to access data is greatly reduced. The access improves by a factor of 10 to 100 depending on the structure of the table and on the exact system configuration.
    If the storage requirements in the buffer increase due to further data, the data that has not been accessed for the longest time is displaced. This displacement takes place asynchronously at certain times which are defined dynamically based on the buffer accesses. Data is only displaced if the free space in  the buffer is less than a predefined value or the quality of the access is not satisfactory at this time.
    Entering $TAB in the command field resets the table buffers on the corresponding application server. Only use this command if there are inconsistencies in the buffer. In large systems, it can take several hours to fill the buffers. The performance is considerably reduced during this time.
    <b>Concept of buffering</b>
    <b>The R/3 System manages and synchronizes the buffers on the individual application servers. If an application program accesses data of a table, the database interfaces determines whether this data lies in the buffer of the application server. If this is the case, the data is read directly from the buffer. If the data is not in the buffer of the application server, it is read from the database and loaded into the buffer. The buffer can therefore satisfy the next access to this data.
    The buffering type determines which records of the table are loaded into the buffer of the application server when a record of the table is accessed. There are three different buffering types.
    With full buffering, all the table records are loaded into the buffer when one record of the table is accessed.
    With generic buffering, all the records whose left-justified part of the key is the same are loaded into the buffer when a table record is accessed.
    With single-record buffering, only the record that was accessed is loaded into the buffer.</b><b>Buffering types</b>
    With full buffering, the table is either completely or not at all in the buffer. When a record of the table is accessed, all the records of the table are loaded into the buffer.
    When you decide whether a table should be fully buffered, you must take the table size, the number of read accesses and the number of write accesses into consideration. The smaller the table is, the more frequently it is read and the less frequently it is written, the better it is to fully buffer the table.
    Full buffering is also advisable for tables having frequent accesses to records that do not exist. Since all the records of the table reside in the buffer, it is already clear in the buffer whether or not a record exists.
    The data records are stored in the buffer sorted by table key. When you access the data with SELECT, only fields up to the last specified key field can be used for the access. The left-justified part of the key should therefore be as large as possible for such accesses. For example, if the first key field is not defined, the entire table is scanned in the buffer. Under these circumstances, a direct access to the database could be more efficient if there is a suitable secondary index there.
    With generic buffering, all the records whose generic key fields agree with this record are loaded into the buffer when one record of the table is accessed. The generic key is a left-justified part of the primary key of the table that must be defined when the buffering type is selected. The generic key should be selected so that the generic areas are not too small, which would result in too many generic areas. If there are only a few records for each generic area, full buffering is usually preferable for the table. If you choose too large a generic key, too much data will be invalidated if there are changes to table entries, which would have a negative effect on the performance.
    A table should be generically buffered if only certain generic areas of the table are usually needed for processing.
    Client-dependent, fully buffered tables are automatically generically buffered. The client field is the generic key. It is assumed that not all of the clients are being processed at the same time on one application server. Language-dependent tables are a further example of generic buffering. The generic key includes all the key fields up to and including the language field.
    The generic areas are managed in the buffer as independent objects. The generic areas are managed analogously to fully buffered tables. You should therefore also read the information about full buffering.
    Single-record buffering is recommended particularly for large tables in which only a few records are accessed repeatedly with SELECT SINGLE. All the accesses to the table that do not use SELECT SINGLE bypass the buffer and directly access the database.
    If you access a record that was not yet buffered using SELECT SINGLE, there is a database access to load the record. If the table does not contain a record with the specified key, this record is recorded in the buffer as non-existent. This prevents a further database access if you make another access with the same key
    You only need one database access to load a table with full buffering, but you need several database accesses with single-record buffering. Full buffering is therefore generally preferable for small tables that are frequently accessed.
    <b>Synchronizing local buffers</b>
    The table buffers reside locally on each application server in the system. However, this makes it necessary for the buffer administration to transfer all changes made to buffered objects to all the application servers of the system.
    If a buffered table is modified, it is updated synchronously in the buffer of the application server from which the change was made. The buffers of the whole network, that is, the buffers of all the other application servers, are synchronized with an asynchronous procedure.
    Entries are written in a central database table (DDLOG) after each table modification that could be buffered. Each application server reads these entries at fixed time intervals.
    If entries are found that show a change to the data buffered by this server, this data is invalidated. If this data is accessed again, it is read directly from the database. In such an access, the table can then be loaded to the buffer again.
    <b>Reward if usefull</b>

  • Extended Length APDU

    Hi all,
    simple question here:
    Is anybody aware of a commercially available (or soon) Java Card implementation that supports extended length APDUs? I really don't care whether its through JC2.2.2 or some proprietary mechanism.
    If you know of something, please let me know. Thanks!
    -mkdata

    I did not see any Java Card smart card which supports extended APDU. I think the problem is the global APDU buffer size on-card. Theoretically, if the card supports extended APDU, it must be able to store up to 65kB in the APDU buffer, which should be by definition transient. There could be a solution with some smart design on-card or proprietary middleware for the reader ...
    Someone mentioned here a company (Athena Smart Card Solutions, Japan) which supports Java Card 2.2.2 . I checked on their web-site and they claim to have extended APDU support as well:
    T=1 Protocol T=1 with PPS for speed enhancement with extended APDU length support ...
    Product Evaluation Evaluation cards are available for this product from the Athena Sales Team
    http://www.athena-scs.com/pdf/IDProtect_lettersize.pdf

  • When it is beter to buffer the table

    hi
    when it is beter to buffer the table

    Hi
    <b>Table buffering</b>
    Advantages of buffering
    Concept of buffering
    Buffering types
    Buffer synchronization
    <b>Database access using Buffer concept</b>
    Buffering allows you to access data quicker by letting you
    access it from the application server instead of the database.
    <b>Advantages of buffering</b>
    Table buffering increases the performance when the records of the table are read.
    As records of a buffered table are read directly from the local buffer of the application server on which the accessing transaction is running, time required to access data is greatly reduced. The access improves by a factor of 10 to 100 depending on the structure of the table and on the exact system configuration.
    If the storage requirements in the buffer increase due to further data, the data that has not been accessed for the longest time is displaced. This displacement takes place asynchronously at certain times which are defined dynamically based on the buffer accesses. Data is only displaced if the free space in  the buffer is less than a predefined value or the quality of the access is not satisfactory at this time.
    Entering $TAB in the command field resets the table buffers on the corresponding application server. Only use this command if there are inconsistencies in the buffer. In large systems, it can take several hours to fill the buffers. The performance is considerably reduced during this time.
    <b>Concept of buffering</b>
    The R/3 System manages and synchronizes the buffers on the individual application servers. If an application program accesses data of a table, the database interfaces determines whether this data lies in the buffer of the application server. If this is the case, the data is read directly from the buffer. If the data is not in the buffer of the application server, it is read from the database and loaded into the buffer. The buffer can therefore satisfy the next access to this data.
    The buffering type determines which records of the table are loaded into the buffer of the application server when a record of the table is accessed. There are three different buffering types.
    With full buffering, all the table records are loaded into the buffer when one record of the table is accessed.
    With generic buffering, all the records whose left-justified part of the key is the same are loaded into the buffer when a table record is accessed.
    With single-record buffering, only the record that was accessed is loaded into the buffer.
    <b>Buffering types</b>
    With full buffering, the table is either completely or not at all in the buffer. When a record of the table is accessed, all the records of the table are loaded into the buffer.
    When you decide whether a table should be fully buffered, you must take the table size, the number of read accesses and the number of write accesses into consideration. The smaller the table is, the more frequently it is read and the less frequently it is written, the better it is to fully buffer the table.
    Full buffering is also advisable for tables having frequent accesses to records that do not exist. Since all the records of the table reside in the buffer, it is already clear in the buffer whether or not a record exists.
    The data records are stored in the buffer sorted by table key. When you access the data with SELECT, only fields up to the last specified key field can be used for the access. The left-justified part of the key should therefore be as large as possible for such accesses. For example, if the first key field is not defined, the entire table is scanned in the buffer. Under these circumstances, a direct access to the database could be more efficient if there is a suitable secondary index there.
    With generic buffering, all the records whose generic key fields agree with this record are loaded into the buffer when one record of the table is accessed. The generic key is a left-justified part of the primary key of the table that must be defined when the buffering type is selected. The generic key should be selected so that the generic areas are not too small, which would result in too many generic areas. If there are only a few records for each generic area, full buffering is usually preferable for the table. If you choose too large a generic key, too much data will be invalidated if there are changes to table entries, which would have a negative effect on the performance.
    A table should be generically buffered if only certain generic areas of the table are usually needed for processing.
    Client-dependent, fully buffered tables are automatically generically buffered. The client field is the generic key. It is assumed that not all of the clients are being processed at the same time on one application server. Language-dependent tables are a further example of generic buffering. The generic key includes all the key fields up to and including the language field.
    The generic areas are managed in the buffer as independent objects. The generic areas are managed analogously to fully buffered tables. You should therefore also read the information about full buffering.
    Single-record buffering is recommended particularly for large tables in which only a few records are accessed repeatedly with SELECT SINGLE. All the accesses to the table that do not use SELECT SINGLE bypass the buffer and directly access the database.
    If you access a record that was not yet buffered using SELECT SINGLE, there is a database access to load the record. If the table does not contain a record with the specified key, this record is recorded in the buffer as non-existent. This prevents a further database access if you make another access with the same key
    You only need one database access to load a table with full buffering, but you need several database accesses with single-record buffering. Full buffering is therefore generally preferable for small tables that are frequently accessed.
    <b>Synchronizing local buffers</b>
    The table buffers reside locally on each application server in the system. However, this makes it necessary for the buffer administration to transfer all changes made to buffered objects to all the application servers of the system.
    If a buffered table is modified, it is updated synchronously in the buffer of the application server from which the change was made. The buffers of the whole network, that is, the buffers of all the other application servers, are synchronized with an asynchronous procedure.
    Entries are written in a central database table (DDLOG) after each table modification that could be buffered. Each application server reads these entries at fixed time intervals.
    If entries are found that show a change to the data buffered by this server, this data is invalidated. If this data is accessed again, it is read directly from the database. In such an access, the table can then be loaded to the buffer again.
    <b>Using buffered tables improves the performance considerably.</b>
    Bypassing the buffer increases the network considerably
    SELECT SINGLE * FROM T100 INTO T100_WA
      BYPASSING BUFFER
      WHERE     SPRSL = 'D'
            AND ARBGB = '00'
            AND MSGNR = '999'.
    The above mentioned code can be more optimized by using the following code
    SELECT SINGLE * FROM T100  INTO T100_WA
      WHERE     SPRSL = 'D'
            AND ARBGB = '00'
            AND MSGNR = '999'.
    <b>Optimizing the load of the database</b>
    <b>Using table buffering</b>
         Using buffered tables improves the performance considerably. Note that in some cases a statement can not be used with a buffered table, so when using these statements the buffer will be bypassed. These statements are:
    Select DISTINCT
    ORDER BY / GROUP BY / HAVING clause
    Any WHERE clause that contains a sub query or IS NULL expression
    JOIN s
    A SELECT... FOR UPDATE
         If you wan t to explicitly bypass the buffer, use the BYPASS BUFFER addition to the SELECT clause.
    <b>Reward if useful</b>

  • Install error -look at the code. plz help

    I have the simple applet that I'm able to compile and load on to a JCOP10 cartd. When I try to install the applet so that I can start interacting with it, I get the following error. How do I go beyond this point? I'll appreciate your help.
    JCOP shell
    Load report:
    747 bytes loaded in 0.0 seconds
    effective code size on card:
    + package AID 6
    + applet AIDs 13
    + classes 21
    + methods 470
    + statics 0
    + exports 0
    overall 510 bytes
         end
         /set-var J 0
         while ${J} < ${PKG_${I}_APP_COUNT}
              install -i ${PKG_${I}_APP_${J}_INST_AID} -q C9#(${PKG_${I}_APP_${J}_INST_DATA}) ${PKG_${I}_AID} ${PKG_${I}_APP_${J}_AID}
    => 80 E6 0C 00 24 06 11 11 11 11 11 11 06 22 22 22 ....$........"""
    22 22 22 06 22 22 22 22 22 33 01 00 0B C9 09 23 """."""""3.....#
    42 38 47 36 74 63 76 73 00 00 B8G6tcvs..
    (0 msec)
    <= 6A 80 j.
    Status: Wrong data
    Error code: 6a80 (Wrong data)
    Offending APDU: 6A80
    Here is the code.
    * Package: myWallet
    * Filename: MyWallet.java
    * Class: MyWallet
    * Date: Jan 23, 2004 2:01:58 PM
    package myWallet;
    import javacard.framework.*;
    //import javacardx.framework.*;
    public class MyWallet extends Applet
    /* constants declaration */
    // code of CLA byte in the command APDU header
    final static byte Wallet_CLA =(byte)0x80;
    // codes of INS byte in the command APDU header
    final static byte VERIFY = (byte) 0x20;
    final static byte CREDIT = (byte) 0x30;
    final static byte DEBIT = (byte) 0x40;
    final static byte GET_BALANCE = (byte) 0x50;
    // maximum balance
    final static short MAX_BALANCE = (byte)0x7FFF;
    // maximum transaction amount
    final static byte MAX_TRANSACTION_AMOUNT =(byte)0x007F;
    // maximum number of incorrect tries before the
    // PIN is blocked
    final static byte PIN_TRY_LIMIT =(byte)0x03;
    // maximum size PIN
    final static byte MAX_PIN_SIZE =(byte)0x08;
    // signal that the PIN verification failed
    final static short SW_VERIFICATION_FAILED = 0x6300;
    // signal the the PIN validation is required
    // for a credit or a debit transaction
    final static short SW_PIN_VERIFICATION_REQUIRED =     0x6301;
    // signal invalid transaction amount
    // amount > MAX_TRANSACTION_AMOUNT or amount < 0
    final static short SW_INVALID_TRANSACTION_AMOUNT = 0x6A83;
    // signal that the balance exceed the maximum
    final static short SW_EXCEED_MAXIMUM_BALANCE = 0x6A84;
    // signal the the balance becomes negative
    final static short SW_NEGATIVE_BALANCE = 0x6A85;
    /* instance variables declaration */
    OwnerPIN pin;
    short balance;
    private MyWallet (byte[] bArray,short bOffset,byte bLength)
         // It is good programming practice to allocate
         // all the memory that an applet needs during
         // its lifetime inside the constructor
         pin = new OwnerPIN(PIN_TRY_LIMIT, MAX_PIN_SIZE);
         byte iLen = bArray[bOffset]; // aid length
         bOffset = (short) (bOffset+iLen+1);
         byte cLen = bArray[bOffset]; // info length
         bOffset = (short) (bOffset+cLen+1);
         byte aLen = bArray[bOffset]; // applet data length
         // The installation parameters contain the PIN
         // initialization value
         pin.update(bArray, (short)(bOffset+1), aLen);
    register();
    } // end of the constructor
    public static void install(byte[] bArray, short bOffset, byte bLength){
         // create a Wallet applet instance
         MyWallet me = new MyWallet(bArray, bOffset, bLength);
    me.register(bArray, bOffset, bLength);
    } // end of install method
    public boolean select()
         // The applet declines to be selected
         // if the pin is blocked.
         if ( pin.getTriesRemaining() == 0 )
         return false;
         return true;
    }// end of select method
    public void deselect() {
         // reset the pin value
         pin.reset();
    public void process(APDU apdu) {
         // APDU object carries a byte array (buffer) to
         // transfer incoming and outgoing APDU header
         // and data bytes between card and CAD
         // At this point, only the first header bytes
         // [CLA, INS, P1, P2, P3] are available in
         // the APDU buffer.
         // The interface javacard.framework.ISO7816
         // declares constants to denote the offset of
         // these bytes in the APDU buffer
         byte[] buffer = apdu.getBuffer();
         // check SELECT APDU command
         buffer[ISO7816.OFFSET_CLA] = (byte)(buffer[ISO7816.OFFSET_CLA] & (byte)0xFC);
         if ((buffer[ISO7816.OFFSET_CLA] == 0) &&
         (buffer[ISO7816.OFFSET_INS] == (byte)(0xA4)) )
         return;
         // verify the reset of commands have the
         // correct CLA byte, which specifies the
         // command structure
         if (buffer[ISO7816.OFFSET_CLA] != Wallet_CLA)
         ISOException.throwIt
    (ISO7816.SW_CLA_NOT_SUPPORTED);
         switch (buffer[ISO7816.OFFSET_INS]) {
         case GET_BALANCE: getBalance(apdu);
                                  return;
         case DEBIT: debit(apdu);
                                  return;
         case CREDIT: credit(apdu);
                                  return;
         case VERIFY: verify(apdu);
                                  return;
         default: ISOException.throwIt (ISO7816.SW_INS_NOT_SUPPORTED);
    } // end of process method
    private void credit(APDU apdu)
    // access authentication
    if ( ! pin.isValidated() )
    ISOException.throwIt(
              SW_PIN_VERIFICATION_REQUIRED);
         byte[] buffer = apdu.getBuffer();
         // Lc byte denotes the number of bytes in the
         // data field of the command APDU
         byte numBytes = buffer[ISO7816.OFFSET_LC];
         // indicate that this APDU has incoming data
         // and receive data starting from the offset
         // ISO7816.OFFSET_CDATA following the 5 header
         // bytes.
         byte byteRead =
                   (byte)(apdu.setIncomingAndReceive());
         // it is an error if the number of data bytes
         // read does not match the number in Lc byte
         if ( ( numBytes != 1 ) || (byteRead != 1) )
         ISOException.throwIt(ISO7816.SW_WRONG_LENGTH);
         // get the credit amount
         byte creditAmount = buffer[ISO7816.OFFSET_CDATA];
         // check the credit amount
         if ( ( creditAmount > MAX_TRANSACTION_AMOUNT)
              || ( creditAmount < 0 ) )
              ISOException.throwIt
                        (SW_INVALID_TRANSACTION_AMOUNT);
         // check the new balance
         if ( (short)( balance + creditAmount) > MAX_BALANCE )
         ISOException.throwIt
                             (SW_EXCEED_MAXIMUM_BALANCE);
         // credit the amount
         balance = (short)(balance + creditAmount);
    } // end of deposit method
    private void debit(APDU apdu)
         // access authentication
         if ( ! pin.isValidated() )
         ISOException.throwIt
    (SW_PIN_VERIFICATION_REQUIRED);
         byte[] buffer = apdu.getBuffer();
         byte numBytes =
                   (byte)(buffer[ISO7816.OFFSET_LC]);
         byte byteRead =
                   (byte)(apdu.setIncomingAndReceive());
         if ( ( numBytes != 1 ) || (byteRead != 1) )
         ISOException.throwIt
                                  (ISO7816.SW_WRONG_LENGTH);
         // get debit amount
         byte debitAmount =
                             buffer[ISO7816.OFFSET_CDATA];
         // check debit amount
         if ( ( debitAmount > MAX_TRANSACTION_AMOUNT)
              || ( debitAmount < 0 ) )
         ISOException.throwIt
                        (SW_INVALID_TRANSACTION_AMOUNT);
         // check the new balance
         if ( (short)( balance - debitAmount ) < (short)0 )
              ISOException.throwIt(SW_NEGATIVE_BALANCE);
         balance = (short) (balance - debitAmount);
    } // end of debit method
    private void getBalance(APDU apdu) {
         byte[] buffer = apdu.getBuffer();
         // inform system that the applet has finished
         // processing the command and the system should
         // now prepare to construct a response APDU
         // which contains data field
         short le = apdu.setOutgoing();
         if ( le < 2 )
         ISOException.throwIt
                             (ISO7816.SW_WRONG_LENGTH);
         //informs the CAD the actual number of bytes
         //returned
         apdu.setOutgoingLength((byte)2);
         // move the balance data into the APDU buffer
         // starting at the offset 0
         buffer[0] = (byte)(balance >> 8);
         buffer[1] = (byte)(balance & 0xFF);
         // send the 2-byte balance at the offset
         // 0 in the apdu buffer
         apdu.sendBytes((short)0, (short)2);
    } // end of getBalance method
    private void verify(APDU apdu) {
         byte[] buffer = apdu.getBuffer();
         // retrieve the PIN data for validation.
    byte byteRead =(byte)(apdu.setIncomingAndReceive());
    // check pin
         // the PIN data is read into the APDU buffer
    // at the offset ISO7816.OFFSET_CDATA
    // the PIN data length = byteRead
    if ( pin.check(buffer, ISO7816.OFFSET_CDATA,byteRead) == false )
         ISOException.throwIt(SW_VERIFICATION_FAILED);
    } // end of validate method
    } // end of class Wallet

    How do I set a breakpoint in my install method in order to identify the error?
    I've tried changing my install method and making it look exactly like the sample wallet applications accompanying the javacard kit, but I'm still getting the same error? here else could be the possible source of the error?
    Thomas

Maybe you are looking for

  • Upgrading from Mountain lion

    I am upgrading from Mountain Lion to Mavericks. I tried to install Mavericks from the AppStore, everything went OK (download, etc), until the system had to reboot and it was when everything failed. The system couldn't start, it stalled when the apple

  • Login failing

    I can log into OTN just fine. When I try to download something (Oracle Application Express) and I click on accept, I'm prompted for the userid/login box. Even though, I'm already logged in. My userid/password that I used a to get in now fails. I've b

  • I purchased two movies on itunes and my ipad cant load them on my ipad

    I pruchased two movies on itunes and for some odd reason i cant load them on my ipad...I have the latest versions of Ios6 and the latest itunes , but the rest of my older movies on itunes i can still load(remove and reload on the ipad). please help!!

  • Best way to replace move in iDVD project?

    Hello, I have an iDVD project started and realized I wanted to change a couple details in the iMovie I imported to the project. I can go back and correct the iMovie, but what's the best way to replace the current movie in the iDVD project with the re

  • My tab button doesn't work.

    My tab button for my Microsoft Word Notebook no longer works. The button use to place a "bullet" down every time I hit 'tab.' This no longer happens and my 'tab' button does not even space forward anymore. Help. This feature makes note taking in clas