IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Advise on TOD Clock usage in PL/1 or COBOL.


IBM Mainframe Forums -> PL/I & Assembler
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
thanoozm

New User


Joined: 23 May 2007
Posts: 26
Location: hyderabad

PostPosted: Wed Jul 25, 2012 2:01 pm
Reply with quote

I have a assembler programme it will use TOD clock and generate the random key. We have decided to move this to COBOL/PL 1.

When I am scanning through manuals, I am not getting direct TOD clock values in COBOL, all functions provided in converted format and I have come across 2043 error.

I am seeking you thoughts and suggestions to use in COBOL (I got some macros to some what near values using CEELOCT and CEEGMTO) and how can I proceed to use in COBOL.
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Wed Jul 25, 2012 2:41 pm
Reply with quote

Please fully describe everything you wrote above.

If you are just looking for a "seed" for the random number, it doesn't matter what "format" you have for TOD or anything else, it just has to be something which will mostly give you a different answer.
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Wed Jul 25, 2012 6:30 pm
Reply with quote

A recent post which may help -

ibmmainframes.com/viewtopic.php?p=295888&highlight=#295888
Back to top
View user's profile Send private message
thanoozm

New User


Joined: 23 May 2007
Posts: 26
Location: hyderabad

PostPosted: Wed Jul 25, 2012 7:16 pm
Reply with quote

Hi Bill woodger & Bill oboyle

Thanks for your replie's.

I have assembler code to generate unique value, i need to convert that into cobol or PL/1.

I TOD(clock) is used as seed to select a charter from below given charter set to generate a 14 byte unique value.

'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789'

Thanks,
tm.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix

PostPosted: Wed Jul 25, 2012 7:26 pm
Reply with quote

Hello,

Is there also a requirement that the new code yields the same answer as the existing code?
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Wed Jul 25, 2012 7:31 pm
Reply with quote

The above link provided returns the STCK as 9-Bytes Packed-Decimal format.

Do you have a previous STCK value that needs converting?

If this is true, then what is the format you need this previous STCK value converted to?
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Wed Jul 25, 2012 7:43 pm
Reply with quote

thanoozm wrote:
generate a 14 byte unique value.

unique to what/in what?
all you are really achieving is a random value.
to be unique, it needs to be compared against all other values generated and used somewhere.

did we not have a similar thread a month or so ago.


dick scherrer wrote:
Hello,

Is there also a requirement that the new code yields the same answer as the existing code?


sure glad i am not the one to attempt to test and prove.
using TOD as seed, how are you going to test a PL1 and a COBOL program????????
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix

PostPosted: Wed Jul 25, 2012 8:56 pm
Reply with quote

Hello,

Quote:
sure glad i am not the one to attempt to test and prove.
Yup icon_smile.gif

I only asked because there may be the chance that "things" already built and stored may need the same calculation to be "found" again or synced with some other data that was stored using the same . . .

Depending on just what is happening, there may also be a need to handle "synonyms" - when 2 values yield the same "random" value.
Back to top
View user's profile Send private message
thanoozm

New User


Joined: 23 May 2007
Posts: 26
Location: hyderabad

PostPosted: Wed Jul 25, 2012 9:24 pm
Reply with quote

Hi Dick sheerer,

We have to get same code what assembler is generating using Cobol/PL1. I am seeing only problem is getting TOD(CLOCK) value in PL1/COBOL is bit difficult.

I am also seeking to give relaxation for that, So that i can generate random value using any algorithm.

Hi Bill,

In your thread i need to call assembler module to get the 9digit packed value in Cobol. Our aim is don't write any new code in assembler.

We are planing to reduce assembler code as much as possible.

I am ok to get STCK value in 8 byte comp varible in cobol. But not using any extra assembler code.

Thanks,
TM.
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Wed Jul 25, 2012 10:35 pm
Reply with quote

As a technician, you probably don't have any problem with called Assembler sub-programs. Unfortunately, it's probably management driving this paranoia train, as Assembler gives them hives. icon_rolleyes.gif

As far as I know, COBOL and PL/I cannot get a TOD/STCK value directly, without calling an Assembler sub-program.

The closest you'll have is issuing a call to the LE Callable routine "CEESECS", using as input, the output (in a designated picture clause) after calling the LE Callable Date routine "CEELOCT", which returns a 17-Byte value of "CCYYMMDDHHMMSSTHM" (M=Milliseconds) as the current local date/time.

The result from "CEESECS" is a COMP-2/64-Bit Floating Point value, representing the number of seconds since midnight 14 October, 1582.

However, the STCK value begins at 1 January, 1900 at midnight. STCK is due to spill-over sometime in September, 2042, so you can get me at the "real" old-folks home. icon_smile.gif

Anyway, back to business, the other dilemma is that many shops have STCK generation aligned with GMT. So, a positive/negative adjustment needs to be applied to the "CEESECS" result by calling the LE/GMT Offset Callable routine "CEEGMTO" and obtain the HHMM to local date/time. As a static, pre-calculated WS value, set it to the number of seconds between 14 October, 1582 and 1 January, 1900.

Note, the COBOL FUNCTION "CURRENT-DATE" returns a 16-Byte value of "CCYYMMDDHHMMSSTH" in positions 01-16 and a +/-HHMM GMT Offset position in positions 17-21. Note that the data/time returned is based upon 1 January, 1601 at midnight, although this can be changed via the compiler option INTDATE=LILIAN, which will base date usage upon the LE standard of 14 October, 1582 at midnight (default is INTDATE=ANSI). With that, COBOL does not offer a FUNCTION to convert this date/time to seconds. But, regardless, all of this should be placed in a standard sub-program.

Looks like you've got some work ahead of you unless you can convince management otherwise.... icon_sad.gif

HTH...
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Wed Jul 25, 2012 11:39 pm
Reply with quote

Me, myself and I said -
Quote:
"As a static, pre-calculated WS value, set it to the number of seconds between 14 October, 1582 and 1 January, 1900".

You can reach this calculation by calling LE Callable Date routine "CEEDAYS", passing the date/time as "190001010000000" and associated picture clause in the 1st two parms and a WS fullword-binary field, which will contain the number of lilian days (IE: WS-LILIAN-DAYS) and will be populated by "CEEDAYS". Then, call "CEESECS" which will return the number of seconds associated with these lilian days. It's safer to use "CEESECS" rather than a calculation example of WS-SECONDS = (WS-LILIAN-DAYS * 86400), due to the uncertainty of leap-year adjustments. "CEESECS" can account for these as well as any other "opportunity". icon_wink.gif
Back to top
View user's profile Send private message
thanoozm

New User


Joined: 23 May 2007
Posts: 26
Location: hyderabad

PostPosted: Wed Jul 25, 2012 11:40 pm
Reply with quote

Hi Bill,

I don't have issue to use Assembler, Management has issue to get resources, so i can't ruled out that. icon_sad.gif

Thank you very much icon_biggrin.gif

I will see how the thing's will change soon.... icon_rolleyes.gif
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> PL/I & Assembler

 


Similar Topics
Topic Forum Replies
No new posts COBOL sorting, with input GDG base COBOL Programming 7
No new posts Need help with ADABAS query (COBOL-AD... All Other Mainframe Topics 0
No new posts Replacing FILLER with FILLER<SeqNu... DFSORT/ICETOOL 2
No new posts Compile Sp Cobol base COBOL Programming 1
No new posts SQLCODE=-311 in Cobol SP-DB2. COBOL Programming 2
Search our Forums:

Back to Top