Application Development Single Source Updates at KLM and tools used The Highlights Michael Bahlen TPF user group Dallas - 15 April 2008

Application Development

Single Source Updates at KLMand tools used

The Highlights

Michael Bahlen

TPF user group Dallas - 15 April 2008

2Single Source at KLM

Single Source Updates

Excitement!

z/TPF Applying Single Source

So many times the same thing!



• Assembler programs- Calling C- Assembler linked into C

• C(++) programs- Packed structures- Packed decimal

• Testing- Stress test- User test

• Tools used



Assembler calling CTo avoid too much work we looked for a simple and quick

method. At first it appeared to be a lot of work finding all ENTRC’s from assembler to C. It also looked like a lot of work to implement the CPROG and CALLC macro’s.

Lucky enough IBM came with a simpler setup for this single source update: UPROC (Put 4 APAR PJ31214).



UPROC in KLMIn the UPROC we call another macro per sub-system. Inside

these macro’s we call macro’s with the same name as the include headers that contain the C-prototype.

MACROUPROCCOPY UPRMDWCOPY UPRRESCOPY UPRDCSCOPY UPRCGOCOPY UPRFIRCOPY UPRSYSCOPY UPRCOMMEND

COPY AVLLNKCOPY AVSLNKCOPY BCELNKCOPY COSLNKCOPY DBULNKCOPY DYNLNKCOPY EDILNKCOPY FDLLNKEtc.

CPROC AVS5,(p,p),RETURN=ui CPROC AVSA,(p,p),RETURN=i CPROC KAVM,(),RETURN=void CPROC KAVS,(),RETURN=void



Transfer vectors!

BEGIN AMODE=31,NAME=PGMA B PGMA B PGMB

BEGIN AMODE=31,NAME=PGMA, > TV=(PGMB,PGMC)* B PGMA* B PGMB

Wrong!

BEGIN AMODE=31,NAME=PGMA, > TV=(PGMB,PGMC) B PGMA B PGMB

OK!



Assembler linked into CWhat to change and how? That was my big question. OK I

knew I had to change to prolog and epilog macro’s. But there was more to do!

Parameters were coming in through a pointer in R1!

Not anymore! Now it is in R2-R6!

So the parameters used are now in registers! That meant I had to re-write most of the code, most of the registers had another usage!



Registers R8 and R13 are to be watched very closely.Do this by usage of the PBASC and CSTCK macros.

If 4K is not enough, use baseless programming, E.g. Jump and immediate instructions. I was able to make a library function under TPF41 of about 60K with only R8 on the 1st 4K of the routine, the rest was baseless…


Single Source Updatesold code

PARMS DSECTPSTR DS F POINTER TO STRING TO CONVERTLL25 CSECT USING PARMS,R3 EXTRN @@TRTSTRUPR TMSPC LWS=R4 LR R3,R1 COPY INPUT POINTER L R1,PSTR GET POINTER TO STRING LR R6,R1 COPY FOR LATER L R2,=A(@@TRT) GET ADDRESS TRT TABLE NEXT EQU * TRT 0(256,R1),0(R2) GET ZERO TERMINATION BYTE BNE LAST FOUND! TR 0(256,R1),UPRTAB NOT FOUND YET, TRANSLATE THIS PART LA R1,256(R1) POINT TO NEXT PART LR R6,R1 COPY AGAIN FOR LATER B NEXT RE-START LAST EQU * SR R1,R6 CALCULATE LENGTH TO DO #EXEC R1,TR,0(0,R6),UPRTAB TRANSLATE THIS (LAST) PART L R15,PSTR POINTER TO RETURN TMSEC RC=R15 RETURN POINTER TO STRING


Single Source Updatesnew code

STRUPR PRLGC FRAMESIZE=0,ENAME=STRUPR,AMODE=31, > BASE=R8,STACK=R13 SR R0,R0 LR R1,R2 For use in SRST instructionNEXT EQU * SRST R0,R2 Find end of the string JO NEXT Continue if not done SLR R0,R1 Calculate length of string LR R2,R1 Go back to start of stringNEXTTR EQU * CHI R0,256 Length within range TR instruction JL LAST Yes, do last part LARL R4, UPRTAB Get address of translate table TR 0(256,R2),0(R4) Do 256 bytes and LA R2,256(R2) Point to the next characters and AHI R0,-256 Reduce length to be done J NEXTTR Next partLAST EQU * LTR R3,R0 Anything left? JNP END If not - we are done BCTR R3,0 Adjust for Execute EX R3,TRANS Do last partEND EQU * EPLGC RC=R1 Return pointer to string


Single Source UpdatesAPAR needed!

If you use this Single Source, the original APAR contains an error that may results in a CTL-09400C dumps:ISO-C STACK OVERFLOW

You also have to apply APAR PJ32314 of put 23!



Packed structuresBefore Toolkit updates_Packed struct t_example{

int x;};

After Toolkit updates#ifdef __370__ _Packed #endif struct t_example{

int x;} #ifndef __370__ __attribute__((packed)) #endif ;

Readability zero after updates!



Even worse at KLM, we did not always use the _Packed keyword but used a definition of:

#define Pstruct _Packed struct

Which is not recognized by the toolkit, E.g.:

Pstruct t_example{

int x;};

So we needed another solution…



We need new defines for TPF4.1 and zTPF1.1

In a generally used include header:

#ifdef __370__ #define Pstruct _Packed struct#define Punion _Packed union#define _PACKED_#else#define Pstruct struct#define Punion union#define _Packed#define _PACKED_ __attribute__((packed)) #endif



Result is a good readable solution:Pstruct t_example{

int x;} _PACKED_;

_Packed struct t_example{

int x;} _PACKED_;

typedef Pstruct t_example _PACKED_ EXAMPLE;typedef _Packed struct t_example _PACKED_ EXAMPLE;



• For usage of #pragma pack, some updates are needed, but they are very simple:

• #pragma pack(pack) becomes #pragma pack(1)

• #pragma pack(reset) becomes #pragma pack()

• This is supported by the IBM C-compiler.



Packed Decimal (in C)

The packed decimal type we know in TPF4.1 does not exist in the GCC-compiler.

Solution: A bunch of functions given by IBM. All we knew about them was there calling names, found in the TPF information center. But watch out, you’ll be using floats in your calculations (less accurate!).

After some tests and searches on the internet we found what to do in our environment.

http://www2.hursley.ibm.com/decimal/decnumber.pdf

http://www2.hursley.ibm.com/decimal/decnumber.pdf



• Packed Decimal

• Other solutions:

• Use the proposed solution for C++ (type library), convert C-code to C++ (just say to the compiler that the C-code is C++). Your programmers need some C++ knowledge.

• Change the GCC compiler to recognize the decimal type. If you do so (its open source!) share it with all other TPF companies, by having it adapted into the standard GCC compiler!



TestingStress-test (live input over a TPF test-system with updated

programs):

We did several stress-tests to prove that the updates did not cause dumps, some of course did, so a new stress-test was needed.

User-test:

What to tell the user to test? How much time do they need?

It all depends on the software updated, result so far:No errors on production system.



Tools used• At first the TPF toolkit (specially installed before the big

roll-out)

• Later IdefixGui (adapted version, will be the zIdefixGui)

Demo of the KLM tool.


Main display of IdefixGui with Demo Grip (collection of sources)


Select Single Source check for Complete Grip


GUI shows progress


Results are written to event file and shown

through an event viewer


After double click Editor opens on place to change


For scanning sources that need Single Source, a special path search is

included.


Result is also passed to the event viewer


For generating assembler prototype, a special function is created to generate

the assembler file containing the CPROC statements


Assembler file before creation of CPROC statements


Assembler file after creation of CPROC statements



Some advice• Train your people before starting in Single Source.

• Do some tests with the toolkit and see what is missing for your way of working.

• Make a ‘complete’ list of adjustments to be done.

• Make workable standards for z/TPF compatible code.E.g. Always use typedef’s for structures

• Make your own scan tools?



User exitsIBM has many new user exits implemented. For us this

results in renaming programs. We knew this may happen, but we never took the time to do so. Result:

UDT1 is now a user exit, but it’s our main date conversion program, with thousands of calls to it!



Some statistics for application software:

Sources Updated

Assembler 10500 5%

Macro's 2300 0%

C(++) 5200 100%

H 3500 95%

Linked assembler 42 100%



Next steps:• Mass recompile with GCC compiler and Linux HLASM

• Solve the errors coming from previous step (zero I hope)

• Load onto a z/TPF test-system and see what happens


Questions?

[email protected]

Documents

Application Development Single Source Updates at KLM and tools used The Highlights Michael Bahlen TPF user group Dallas - 15 April 2008