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...

I have a copybook containing all (current) languages as defined by the standard ISO639-2 as conditional names. All fine at well but to my surprise a program using this copybook does not compile using fujitsu COBOL85 version V30L10. The compile step produces the following error message...

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...

I was awaiting some criticism on the code provided. Note: I know it is weekend now, but I don't have much time for the forum in the coming days...that is why I (try to) anticipate on 'to be expected' criticism. For instance I implicitly use the special register 'LENGTH OF' and the 'ADDRESS'...

Dilettante, Thanks for your constructive input. But I think we are discussing two different issues here! First of all...as a (personal) rule...I define (in almost all cases) all my workfields in just one 01-level definition. In my experience I have found it valuable to have these workfields...

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...

For those interested... It is not uncommon to use the timestamp as a unique (log) registration field. Of course, any timestamp field has a limited accuracy! The chances on duplicates is real and often high! The standard 'FUNCTION CURRENT-TIME' is by no means sufficient. This current...

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!]

Glenn When I said "it cannot be overwritten" I meant it is not allowed to be modified by some creative programmer! And this is exactly why I favor the 77-level definition in this case! Because it is a hell of a lot easier to code a small routine that automatically verifies [and refuses!]...

I myself am not a great advert of using 77 level data definitions. It cannot be re-defined, renamed or grouped. But sometimes these are exactly the characteristics that you want! Example: Program A calls B, B calls C, C calls D, D calls...ad infinitum Suppose an exception occurs in program...

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...