Static call problem in COBOL

chidambaram · New User Joined: 16 Oct 2007 Posts: 11 Location: Chennai

Dears,

Can anyone please help me to identify What is the issue here.

Main Cobol ---- Sub cobol --- Assembler (Getting time using TIME macro)

I am calling the sub cobol program through static call and from that sub cobol I am calling the assembler program also as static - then I am getting the time from assembler as 1 hour less than the local time.

If I am changing any one of this call as dynamic then I am getting the correct time from assembler.

Please help me to identify what is the problem in the first case?

Thanks,
Chipu

Bill O'Boyle · Posted: Wed Nov 11, 2009 8:03 pm

Is this BATCH or CICS?

Are you using non-reentrant program-storage within the sub-program or are you passing COBOL storage to the sub-program?

Are you corrupting R12 in the sub-program? Probably not, but I thought I'd ask.

Is the sub-program LE compliant?

Are you using the Time Macro SVC 11 (LINKAGE=SVC) or LINKAGE=SYSTEM (Cross-Memory Services)?

Bill

chidambaram · New User Joined: 16 Oct 2007 Posts: 11 Location: Chennai

Both the cobol programs are DC-Batch program.

This is the command used in assembler to get time.

TIME DEC,CLOCK,ZONE=LT,LINKAGE=SYSTEM,DATETYPE=YYYYMMDD

enrico-sorichetti · Posted: Wed Nov 11, 2009 8:25 pm

maybe using a dynamic call uses a different assembler <thingy>

very low probability that a different calling method would change a result by exactly one hour

but given enough proof I am willing to change idea ( after having it tested myself )

seem to me that the problem determination is a bit flaky

Robert Sample · Posted: Wed Nov 11, 2009 8:49 pm

It would be interesting to see if the difference is still there when using UTC instead of LT.

chidambaram · New User Joined: 16 Oct 2007 Posts: 11 Location: Chennai

Dear,

If I am using UTC then I am getting one hour difference in both Static / Dynamic calls.

Thanks,
Chipu

Robert Sample · Posted: Wed Nov 11, 2009 9:21 pm

Now that is interesting -- and totally contrary to the concept of UTC which is supposed to be invariant. Which implies something in a program is doing something to the time to create the difference.

chidambaram · New User Joined: 16 Oct 2007 Posts: 11 Location: Chennai

Thanks Robert.

But my question here is how the time is varying even though if I am using the same module for STATIC and DYNAMIC?

Is anything like assembler will support some calling method only?

Any guess where the Problem is exactly coming?

Thanks,
Chipu

Bill O'Boyle · Posted: Wed Nov 11, 2009 9:47 pm

Assuming that CLOCK is the 16-Byte area which gets populated with the time/date, bytes 01-08 format is X'HHMMSSTHMIJU0000', with bytes 07-08 always X'0000' and bytes 09-16 format as X'YYYYMMDD00000000'.

Also, define a 64-Byte (16-Word) savearea and issue a STAM R0,R15,SAVEAREA before invoking the Macro and issue a LAM R0,R15,SAVEAREA after control is returned from the Macro.

The z/OS manual says that the access-registers are modified by LINKAGE=SYSTEM, so they need to be saved and restored.

Are you certain that R15 is zero after the macro returns to the sub-program, regardless whether it's a static or dynamic call?

Bill

Bill O'Boyle · Posted: Wed Nov 11, 2009 11:48 pm

Would you be allowed by your management to post the entire sub-program, surrounded by the appropriate "code" and "/code" BBcodes? Shouldn't be too many lines.

You can return the untouched R15 (from the Macro) to the COBOL caller, who can then interrogate the COBOL SPECIAL-REGISTER RETURN-CODE.

At the end of your sub-program, use the RETURN Macro -

Ronald Burr · Posted: Wed Nov 11, 2009 11:53 pm

My guess would be that the STATIC call is picking up a different module than the DYNAMIC call. I've seen it happen before. To investigate
1) Where are you INCLUDEing the module from ( SYSLIB ) for STATIC call?
2) Where is the module being loaded from for DYNAMIC call? Don't ASSUME it's the same library - check it out by looking for the module in the order of libraries allocated when the module is called dynamically. I'll bet that
a) the module is being loaded from different libraries, and that
b) the module being loaded for dynamic call is one with UTC coding.