NDM Vs FTP

Recently i have come to know about NDM protocol . NDM was designed for File transfer between Mainframe systems. Later  on it was used for  other computers . It best suitable for  large files.
It offer various features like data compression and checkpoint restart .
given below are the few differences between NDM and FTP .

NDM offers for logging, audit, and control features.

FTP does not have elaborate processes for logging and auditing. 

NDM is an asset when dealing with large data packets through its fully automated feature.

FTP requires thorough follow-up of the processes for file transfers and downloads. 

Data security is guaranteed with NDM which offers encryption.

FTP has the encryption option desired for improved data security.

NDM compresses data and therefore uses a low bandwidth.

FTP does not compress data and uses a higher bandwidth.

The checkpoint restart feature is offered in NDM.

FTP does not allow for checkpoint restart. 

NDM offers pre- and post-processing features.

FTP only has post-processing features.

Read more:  Differences Between NDM and FTP | Difference Between http://www.differencebetween.net/technology/differences-between-ndm-and-ftp/#ixzz5kzyrtowE

NDM later was taken by IBM . It is  now known as CONNECT:DIRECT 

ONNECT:Direct (NDM)is a product of Sterling Commerce www.stercomm.com. It is a product designed to automate and manage the exchange of files between two computers. Some of the major differences between the two:

• CONNECT:Direct provides logging, statistics. and audit control features.
• CONNECT:Direct has a built-in scheduling system for automating file transfers.
• CONNECT:Direct manages the file transfer process once it has been submitted.
• CONNECT:Direct can use both TCP/IP and SNA networking protocols as well as direct channels between computers.
• CONNECT:Direct has batch, CICS, ISPF, and web-based interfaces.
• CONNECT:Direct has its own scripting (i.e. process) language.
• CONNECT:Direct has pre- and post-processing features.
• CONNECT:Direct can be monitored with SNMP and/or other automation tools.
• CONNECT:Direct allows you to track what is happening while a transfer is happening, as well as tracking the final status of the file exchange process.
• CONNECT:Direct works with all data types (QSAM, VSAM, PDS, binary).
• CONNECT:Direct can interface with your JES Spool output.
• CONNECT:Direct can interface with your email server.
• CONNECT:Direct can scan directories for the presence of a file, and then initiate a transfer process upon receipt of the file within that directory.
• One vendor means that there are no compatibility issues.
• Check-point restarts of large transfers.

Read more: http://ibmmainframes.com/about9768.html#ixzz5l08CX0PD

volatile usage --problem

import java.util.ArrayList;



public class ThreadTest {

public static void main(String[] args) {

ArrayList arr = new ArrayList();

TestTwo bobj = new TestTwo();

for (int  i =0; i<10 font="" i="">
arr.add(new MyTh(i,bobj));


for (int  i =0; i<10 font="" i="">
{
((Thread ) arr.get(i)).start();


}

}

}



class MyTh extends Thread{


int  num ;

static int  age ;


volatile StringBuffer buff = new StringBuffer("0");

static  StringBuffer buff2 = new StringBuffer("0");

TestTwo obj ;

MyTh (int  k, TestTwo cobj )

{this.num=k; 
this.obj=cobj;} 

@Override
public void run() {

if(this.num==6){
//setAge(40);
this.obj.count.append("hi");
this.buff.append("hi");
this.buff2.append("hi");
this.age =40;
    }
System.out.println(Thread.currentThread().getName() + " :"+this.num + ":" + this.age +":"+
" :[" +this.buff2 +":"+ this.buff2.hashCode() + 
    "] : [" + this.buff + " :"+ this.buff.hashCode() +"] :[ "+ this.obj.count+ ":"+this.obj.count.hashCode() +":]");

}

int   getAge(){
return age;
}

void  setAge(int  k){
this.age =k;
}

}


class TestTwo {

volatile StringBuffer count = new StringBuffer("0");


}


------------



Thread-0 :0:0: :[0:1740525517] : [0 :1769581898] :[ 0:1833313469:]
Thread-1 :1:0: :[0:1740525517] : [0 :857628581] :[ 0:1833313469:]
Thread-2 :2:0: :[0:1740525517] : [0 :1498557318] :[ 0:1833313469:]
Thread-3 :3:0: :[0:1740525517] : [0 :1419206900] :[ 0:1833313469:]
Thread-4 :4:0: :[0:1740525517] : [0 :313434985] :[ 0:1833313469:]
Thread-5 :5:0: :[0:1740525517] : [0 :1644604984] :[ 0:1833313469:]
Thread-6 :6:40: :[0hi:1740525517] : [0hi :1055613344] :[ 0hi:1833313469:]
Thread-7 :7:40: :[0hi:1740525517] : [0 :1151033700] :[ 0hi:1833313469:]
Thread-8 :8:40: :[0hi:1740525517] : [0 :1472482392] :[ 0hi:1833313469:]
Thread-9 :9:40: :[0hi:1740525517] : [0 :1908885604] :[ 0hi:1833313469:]

Java Tidbits .........(char vs byte stream )

A stream is a way of sequentially accessing a file. In Streams you can process the data one at a time as bulk operations are unavailable with them. But, streams supports a huge range of source and destinations including disk file, arrays, other devices, other programs etc. In Java, a byte is not the same thing as a char . Therefore a byte stream is different from a character stream. So, Java defines two types of streams: Byte Streams and Character Streams .

Byte Streams

A byte stream access the file byte by byte. Java programs use byte streams to perform input and output of 8-bit bytes. It is suitable for any kind of file, however not quite appropriate for text files. For example, if the file is using a unicode encoding and a character is represented with two bytes, the byte stream will treat these separately and you will need to do the conversion yourself. Byte oriented streams do not use any encoding scheme while Character oriented streams use character encoding scheme(UNICODE). All byte stream classes are descended from InputStream and OutputStream .

Obtain the count of total rows from SQL query bounded by rownum

Below query i used in a  project where  TOTAL count was obtained  even when Query is bounded by rownum on both ends .


select * from (select PART_NR,CTRY_CD,CUST_TRF_CD,VAL_FROM_DT,CHG_DT,NAT_HS_CD_2 , ROW_NUMBER() OVER(ORDER BY  CHG_DT,PART_NR) AS ID,
 COUNT(1) OVER ( ORDER BY 1 RANGE BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING ) ROW_COUNT from
((select TRIM(A.PART_NR) as PART_NR, TRIM(A.CTRY_CD) as CTRY_CD, TRIM(A.CUST_TRF_CD) as CUST_TRF_CD ,TO_CHAR(A.VAL_FROM_DT ,'yyyymmddhh24miss') as VAL_FROM_DT, TO_CHAR(A.CHG_DT ,'YYYYMMDDhh24miss') as CHG_DT,(case when (A.NAT_HS_CD is null  and A.CUST_TRF_CD is not null)  then
(select TRIM(C.NAT_HS_CD) from (select * from  (select CUST_TRF_CD, CTRY_CD, NAT_HS_CD ,VAL_FROM_DT from CLA_NAT_HS_DETAIL where CTRY_CD =421
 and INVALID_CD=0) AA where  VAL_FROM_DT= (select max(VAL_FROM_DT) from (select CUST_TRF_CD, CTRY_CD, NAT_HS_CD ,VAL_FROM_DT from CLA_NAT_HS_DETAIL
 where CTRY_CD  =421   and INVALID_CD=0) TT  where AA.CUST_TRF_CD=TT.CUST_TRF_CD and AA.CTRY_CD=TT.CTRY_CD) ) C where  C.CUST_TRF_CD=A.CUST_TRF_CD and
 C.CTRY_CD=A.CTRY_CD )  else TRIM(A.NAT_HS_CD)  end) as NAT_HS_CD_2 from cla_cust_part_ctry A where
 A.ctry_cd =421  and  A.CHG_DT between TO_DATE( '20110713000000', 'yyyymmddhh24miss') and TO_DATE( '20110714000000', 'YYYYMMDDhh24miss') and
 TRIM(A.PART_NR) not like '% %' ))  where  NAT_HS_CD_2 is not null) where ID > 20 and ID < 46 order by ID asc 

WebService TitBit-8

Subresources and Runtime Resource Resolution

You can use a resource class to process only a part of the URI request. A root resource can then implement subresources that can process the remainder of the URI path.

A resource class method that is annotated with @Path is either a subresource method or a subresource locator:

• A subresource method is used to handle requests on a subresource of the corresponding resource.
• A subresource locator is used to locate subresources of the corresponding resource.

Subresource Methods

A subresource method handles an HTTP request directly. The method must be annotated with a request method designator such as @GET or @POST, in addition to @Path. The method is invoked for request URIs that match a URI template created by concatenating the URI template of the resource class with the URI template of the method.

The following code snippet shows how a subresource method can be used to extract the last name of an employee when the employee’s email address is provided:

@Path("/employeeinfo")
Public class EmployeeInfo {

    public employeeinfo() {}

    @GET
    @Path("/employees/{firstname}.{lastname}@{domain}.com")
    @Produces("text/xml")
    public String getEmployeeLastName(@PathParam("lastname") String lastName) {
       ...
    }

}

The getEmployeeLastName method returns doe for the following GET request:

GET /employeeinfo/employees/john.doe@example.com

Subresource Locators

A subresource locator returns an object that will handle an HTTP request. The method must not be annotated with a request method designator. You must declare a subresource locator within a subresource class, and only subresource locators are used for runtime resource resolution.

The following code snippet shows a subresource locator:

// Root resource class
@Path("/employeeinfo")
public class EmployeeInfo {

    // Subresource locator: obtains the subresource Employee
    // from the path /employeeinfo/employees/{empid}
    @Path("/employees/{empid}")
    public Employee getEmployee(@PathParam("empid") String id) {
        // Find the Employee based on the id path parameter
        Employee emp = ...;
        ...
        return emp;
    }
}

// Subresource class
public class Employee {

    // Subresource method: returns the employee's last name
    @GET
    @Path("/lastname")
    public String getEmployeeLastName() {
        ...
        return lastName
    }
}

In this code snippet, the getEmployee method is the subresource locator that provides the Employee object, which services requests for lastname.

If your HTTP request is GET /employeeinfo/employees/as209/, the getEmployee method returns an Employee object whose id is as209. At runtime, JAX-RS sends a GET /employeeinfo/employees/as209/lastname request to the getEmployeeLastName method . The getEmployeeLastName method retrieves and returns the last name of the employee whose id is as209.

WebService TitBit-7

Status

This text is the proposed revised replacement text for the 2nd last paragraph in part 1, section 2.6 which reads as follows:

If the SOAP node is a SOAP intermediary, the SOAP message pattern and results of processing (e.g. no fault generated) MAY require that the SOAP message be sent further along the SOAP message path. Such relayed SOAP messages MUST contain all SOAP header blocks and the SOAP body from the original SOAP message, in the original order, except that SOAP header blocks targeted at the SOAP intermediary MUST be removed (such SOAP blocks are removed regardless of whether they were processed or ignored). Additional SOAP header blocks MAY be inserted at any point in the SOAP message, and such inserted SOAP header blocks MAY be indistinguishable from one or more just removed (effectively leaving them in place, but emphasizing the need to reinterpret at each SOAP node along the SOAP message path.)

The text builds on the proposed wording for resolving issue 137 by Noah and Henrik and discussion at the W3C f2f meeting in Cannes.
The idea here is to cast relaying as a feature - it builds on section 2.

2.7 Relaying SOAP Messages

As mentioned earlier in this section, SOAP provides a distributed processing model that assumes that a SOAP message originates at an initial SOAP sender and is sent to an ultimate SOAP receiver via zero or more SOAP intermediaries. While SOAP does not itself define any routing or forwarding semantics, it is anticipated that such functionality can be described as one or more features and expressed as SOAP extensions or as part of the underlying protocol binding (see section 5 and 6). The purpose of this section is to describe how message forwarding interacts with the SOAP distributed processing model.

SOAP Intermediaries

The semantics of one or more SOAP blocks in a SOAP message, or the SOAP message exchange pattern used MAY request that the SOAP message be forwarded to another SOAP node on behalf of the initiator of the inbound SOAP message. In this case, the processing SOAP node acts in the role of a SOAP intermediary.

SOAP defines two different types of intermediaries: forwarding intermediaries and active intermediaries. These two type of intermediary are described below.

Forwarding Intermediaries

Forwarding intermediaries process the message according to the SOAP processing model defined in section 2.6. SOAP header blocks targeted at the SOAP intermediary MUST be removed from the SOAP message prior to forwarding (such SOAP blocks are removed regardless of whether they were processed or ignored).

It is the responsibility of the feature defining the SOAP forwarding to describe the required semantics including rules describing how the forwarded message is constructed. Such rules MAY describe placement of inserted or reinserted blocks. Inserted SOAP header blocks may be indistinguishable from one or more of the header blocks removed above (effectively leaving them in place, but emphasizing the need to reinterpret at each SOAP node along the SOAP message path.)

Active Intermediaries

In addition to the processing performed by forwarding intermediaries, active intermediaries undertake additional processing that may modify the outbound message in ways not described in the inbound message. I.e. they may undertake processing not described by header blocks in the incoming message. The potential set of services provided by an active intermediary includes, but is not limited to: logging, security, content modification and tracing.

The collective effect of such additional processing may affect the correct processing of features expressed in the inbound message by downstream SOAP nodes. For example, as part of generating an outbound message, an active intermediary may have removed and encryped some or all of the blocks found in the inbound message.

It is STRONGLY RECOMMENDED that features provided by active intermediaries be described in a manner that allows such modifications to be detected by the affected SOAP nodes. For example, an active intermediary may describe the processing performed by inserting header blocks into the outbound SOAP message that inform downstream SOAP nodes acting in roles whose correct operation depends on receiving such notification. The semantics of such inserted headers should also call for either the same or other headers to be (re)inserted at subsequent intermediaries as necessary to ensure that the message can be safely processed by nodes yet further downstream. For example, if a message with headers removed for encryption passes through a second intermediary (without the original headers being decrypted and reconstructed), then indication that the encryption has occurred must be retained in the second relayed message.

WebService TitBit-6

Components of EJB-JAR.xml


 < ejb-jar >
     < assembly-descriptor >
         < method-permission >
             < description > The employee and temp-employee roles may access any
                method of the EmployeeService bean  < / description >
             < role-name > employee < / role-name >
             < role-name > temp-employee < / role-name >
             < method >
                 < ejb-name > EmployeeService < / ejb-name >
                 < method-name > * < / method-name >
             < / method >
         < / method-permission >
         < method-permission >
             < description > The employee role may access the findByPrimaryKey,
                getEmployeeInfo, and the updateEmployeeInfo(String) method of
                the AardvarkPayroll bean  < / description >
             < role-name > employee < / role-name >
             < method >
                 < ejb-name > AardvarkPayroll < / ejb-name >
                 < method-name > findByPrimaryKey < / method-name >
             < / method >
             < method >
                 < ejb-name > AardvarkPayroll < / ejb-name >
                 < method-name > getEmployeeInfo < / method-name >
             < / method >
             < method >
                 < ejb-name > AardvarkPayroll < / ejb-name >
                 < method-name > updateEmployeeInfo < / method-name >
                 < method-params >
                     < method-param > java.lang.String < / method-param >
                 < / method-params >
             < / method >
         < / method-permission >
         < method-permission >
             < description > The admin role may access any method of the
                EmployeeServiceAdmin bean  < / description >
             < role-name > admin < / role-name >
             < method >
                 < ejb-name > EmployeeServiceAdmin < / ejb-name >
                 < method-name > * < / method-name >
             < / method >
         < / method-permission >
         < method-permission >
             < description > Any authenticated user may access any method of the
                EmployeeServiceHelp bean < / description >
             < unchecked/  >
             < method >
                 < ejb-name > EmployeeServiceHelp < / ejb-name >
                 < method-name > * < / method-name >
             < / method >
         < / method-permission >
         < exclude-list >
             < description > No fireTheCTO methods of the EmployeeFiring bean may be
                used in this deployment < / description >
             < method >
                 < ejb-name > EmployeeFiring < / ejb-name >
                 < method-name > fireTheCTO < / method-name >
             < / method >
         < / exclude-list >
     < / assembly-descriptor >
 < / ejb-jar >