|
View previous topic :: View next topic
|
| Author |
Message |
thanoozm
New User
.jpg)
Joined: 23 May 2007
Posts: 26
Location: hyderabad
|
|
|
|
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 |
|
 |
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
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 |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
| Back to top |
|
|
thanoozm
New User
Joined: 23 May 2007
Posts: 26
Location: hyderabad
|
|
|
|
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 |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Hello,
Is there also a requirement that the new code yields the same answer as the existing code? |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
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 |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
| 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 |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| sure glad i am not the one to attempt to test and prove. |
Yup 
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 |
|
|
thanoozm
New User
Joined: 23 May 2007
Posts: 26
Location: hyderabad
|
|
|
|
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 |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
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. 
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.
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.... 
HTH... |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
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".  |
|
| Back to top |
|
|
thanoozm
New User
Joined: 23 May 2007
Posts: 26
Location: hyderabad
|
|
|
|
Hi Bill,
I don't have issue to use Assembler, Management has issue to get resources, so i can't ruled out that.
Thank you very much 
I will see how the thing's will change soon.... |
|
| Back to top |
|
|
|
|
