CICS and assembler connectivity

dsivapradeep · New User Joined: 06 Jul 2012 Posts: 43 Location: INDIA

Hi all,

Im new to assembler and knew that assembler supports cics online transactions.
But how feasible is it to use assembler for cics and what will be the advantage of assembler over Cobol ?

I want to learn implementing online cics applications using assembler. Can anyone provide pointers for the resources?

enrico-sorichetti · Posted: Mon Aug 13, 2012 9:23 pm

the CICS manuals contain all You mght want to know about using assembler to develop CICS applications

for example
Application Programming Guide
publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DFHP3C00/CCONTENTS?SHELF=DFHASJ00&DN=SC34-6818-00&DT=20070619105120

dick scherrer · Posted: Mon Aug 13, 2012 9:48 pm

Hello,

These days there is basically no advantage to writing "applications" in assembler - either in CICS or in batch.

Most organizatons do not permit assembler code to be used by applicaton developers as there are fewer and fewer who know assembler well enough to keep large systems running.

dsivapradeep · New User Joined: 06 Jul 2012 Posts: 43 Location: INDIA

Hi dick, Then learning and exploring assembler is of no use in today's IT industry?

People are avoiding assembler because its difficult to develop applications using it or because it is not capable to meet the application requirements?

dick scherrer · Posted: Mon Aug 13, 2012 10:03 pm

Hello,

It still can be of use to know assembler. It is most helpful even if you do not develope new code using assembler.

Organizatons avoid assembler because there are no longer lots of coders that understand assembler. It is not "more difficult" (imho) - if you know it, it is quite usable.

Bill O'Boyle · Posted: Tue Aug 14, 2012 3:18 am

Primarily over the years, Assembler has been used for sub-programs, which can address certain control blocks that HLL can't address (without potential grief) as well as specialties which HLL can't perform.

Normally, the HLL caller is coupled with both HLL sub-programs as well as Assembler sub-programs.

HLL and Assembler make good partners, but with Assembler falling out of favor over the years (as Dick has said), do to the reduced number of programmers who can code it, it has become a liability.

We have interns entering our employee work force (from USC) in South Carolina, but Assembler is omitted from the course study, because management feels it is unnecessary to learn.

Let's face it, Assembler programmers are either dying or retiring and that's just how it goes....

dick scherrer · Posted: Tue Aug 14, 2012 8:38 am

Nic Clouston · Posted: Tue Aug 14, 2012 11:22 am

Bill O'Boyle · Posted: Wed Aug 15, 2012 8:09 pm

Nic,

I hear ya.

IBM's Statement of Direction from a CICS standpoint has been OpenAPI/Threadsafe and here are the issues.

Long ago and far away, when CICS HLL "CALLS" (not LINKS) to a sub-program, the storage used by the Assembler sub-program is it's own, sort of like when you have NORENT used in a COBOL compile. So, the bottom line is, the storage is non-reentrant as it is incorporated as part of the load module.

OpenAPI/Threadsafe requires that the storage used by a given thread is re-entrant and can't be trampled on by another task, which in the above example, would be a problem because with OpenAPI/Threadsafe you'd have multiple TCB's executing the same program (task) concurrently, with each task walking all over the Assembler's storage simultaneously, causing unexpected results and leaving programmer's scratching their heads.

With that, the HLL Caller's should be passing their own re-entrant WS to the Assembler sub-program and the sub-program must use this re-entrant storage, eliminating any of these "opportunities".

But not only should this apply to OpenAPI/Threadsafe, it should be used in all HLL Calling Assembler sub-programs, which has been my approach for several decades. I've seen Assembler storage overlayed by a concurrent task (a single QR TCB) as the logic path was different in the sub-program and corrupted storage ensued.

So, you're right, this could be something that raises some possible Business opportunities for Technical folks down the road to make these changes and allow OpenAPI/Threadsafe compliance. For example, I was getting a S0C1 on an "OR Immediate"? Crazy stuff.

HTH....