Search results for query: *

ceh4702 Thanks for your input! The timestamp as described is not intended as an ID but as a unique timestamp to time-register concurrent events. As such it can only consist of digits. E.g. a public (database) field is updated and later read and updated by other (concurrent) users. That is why...

PHV, Thanks for the list! I am embarressed by the fact that I did not have the 'fujitsu' reserved list (my roots are in the IBM mainframe environment). On the other hand I am relieved that it was not a trivial coding error! And then there is the fact of the compiler not warning me having used...

...copybook does not compile using fujitsu COBOL85 version V30L10. The compile step produces the following error message: (fujitsu COBOL85 V30L10) ** DIAGNOSTIC MESSAGE ** (EXAMPLE2) ISO639$2 217: JMN1123I-S INVALID WORD '88' IS FOUND. IGNORED UNTIL NEXT VALID PARAGRAPH,SECTION OR DIVISION...

dilettante This discussion veered of into another direction...but that is ok! You seem to be a passionate analyst. I say analyst and not programmer because I consider programming less important than the analysis itself. This is my background (and passion!)... In my experience I have found...

Dilettante Maybe I expressed myself poorly! By no means was it my intention to criticize your 'style' or even suggest my 'style'. On the contrary! You actually provided a valid reason to use 77-level parameters (more efficient in heavy duty loops!). As you no doubt have experienced yourself...

...view! Here is the code: (Note: due to the forum box limitations some statements 'overflow' to the next line! Just copy&paste the text to your own *.txt file! Than it will be easier to read!). IDENTIFICATION DIVISION. PROGRAM-ID. TIMESTMP. *--- * Faking(!) a more...

...a noticable performance degradation Between using: 01 a-whole-bunch-of-fields. 05 field1 05 field2 05 ... 05 FieldZillionth AND: * a-whole-bunch-of-fields. 01 field1 *> 01 can also be 77 01 field2 01 ... 01 FieldZillionth I am just curious! I never...

Additional note... Due to the box limitations the following statements look odd: 05 BIN REDEFINES PTR PIC 9(09) BINARY. 05 pseudoCount PIC 9(02) BINARY. This should (of course!) be: 05 BIN REDEFINES PTR PIC 9(09) BINARY. 05 pseudoCount PIC...

...as follows: 05 myTIMESTAMP PIC X(30). CALL TIMESTMP USING myTIMESTAMP Which calls... IDENTIFICATION DIVISION. PROGRAM-ID. TIMESTMP. *--- * Faking(!) a more accurate timestamp! * * The guaranteed accuracy (in seconds) PER USER is: * Inverse (100 * 100 * 999,999) / 2 =...

Webrabbit said: Unfortunaly it does! ...sometimes... In my specific case it does not matter. How and why is not important here. But you are right! 01 and 77 should both be aligned. See, among other: http://docs.hp.com/cgi-bin/doc3k/B3150090004.10451/10 And I quote this source: non-alignment...

Forgot to tell! Any mis allignment is taken care of by the routine! [redundancy check!]

...PIC X(100). 05 someOtherControlData PIC X(..). PROCEDURE DIVISION USING someUserData controlData. begin. * next call MUST BE first line after procedure! * checked by automatic source verification * routine BEFORE the source is even allowed * to be compiled...

...in a field in the called program: PROGRAM-ID. programC. 77 saveCallerID PIC X(100). MOVE callerIDpassedInLinkage TO saveCallerID . . * later some other program(s), programD, * might be called. * programD, in turn, might call 'E', * 'E', in turn, might call 'F', etc. CALL programD...

Something like this? (untested JCL!!...I don't work with mainframes anymore!) //MYJOB JOB MYJOB,'HELLO', // CLASS=A,NOTIFY=ME,USER=ME //* //JS0010 EXEC PGM=IEBCOPY //* //SYSPRINT DD SYSOUT=* //FROM DD DSN=PROD.GDG(0), // DISP=SHR //TO DD DSN=MY.TEST.PS, //...

Oops... Looks that I misunderstood the problem! After rereading it looks that you are just trying to move a constant into a variable. And the contents happens to be an SQL statement. If this is the case then this has nothing to do with SQL whatsover but just with the normal COBOL continuation...

I don't know RM/COBOL. I am familiar with COBOL II and DB2. COBOL II (a COBOL-85 compliant) compiler does (did?) not have a 'built-in' SQL translator. In order to include SQL a precompiler was necessary. This precompiler generated the necessary COBOL code. With regard to the SQL statements...

Earlier I promised some templates. It seems to me that others, specifically Tom Morrison, has the technical know-how you actually need. I assume that it is enough, I will not distract you with design issues (thus dropping my promise). Note: If you are interested in design issues then drop me a...

Implementing switches are vendor dependent! This should have been described in your vendor documentation. The following might be an alternative: (also vendor dependent but to my knowledge more commonly used) Instead of using switches you may consider passing switches as parameters. (or...

I promised some templates...but later (sorry about that) Just a quick reply to: AmorilloElvis: I don't know instantSQL (except of what I read in the link posted by Tom, see above) but I know that MySQL is NOT a fully developed relational database (note: maybe it has become one in the latest...

Yes, I have COBOL templates for SQL CRUD. I don't have them with me at this moment, but I will publish them soon. But, more importantly, please understand the following: Isolate your (business) logic from your physical implementation! That is; create a separate logical/physical conversion...