Re: Db2dclgn Indicator variables

Yes and no.

It is true that "49-levels" are used by most (all?) SQL products for holding
the length for VARCHAR fields. However, they are NOT "special level" numbers
like 77 or 66 that have any specific meanings to COBOL.

You can code:

01 Group.
49 This Pic X.
49 That Pic 9.
49 Whatever occurs 10 times
Pic XXX.

--
Bill Klein
wmklein <at> ix.netcom.com
"Michael Russell" <Michael.Russell@xxxxxxx> wrote in message
news:HbidnaNTNM82qS7YnZ2dnUVZ8s6gnZ2d@xxxxxxxxxxxx
top post.

Aren't level-49s there for lengths of varchars?

Regards

Michael

Frank Swarbrick wrote:

For instance, I'd love to see a COBOL that supports the ANY LENGTH PREFIXED
clause for a much more natural VARCHAR. Just think of it:

01 EMPLOYEE.
05 EMPNO PIC X(6).
05 FIRSTNME PIC X ANY LENGTH
LIMIT IS 12 PREFIXED BY BINARY-SHORT.
05 MIDINIT PIC X(1).
05 LASTNAME PIC X ANY LENGTH
LIMIT IS 15
PREFIXED BY BINARY-SHORT.
05 WORKDEPT PIC X(3).

EXEC SQL
FETCH EMPNO, FIRSTNME, MIDINIT, LASTNAME, WORKDEPT
FROM EMPLOYEE
INTO :EMPNO, :FIRSTNME, :MIDINIT, :LASTNAME, :WORKDEPT
END-EXEC

MOVE 'NEWNAME' INTO LASTNAME
EXEC SQL
UPDATE EMPLOYEE
SET LASTNAME = :LASTNAME
WHERE CURRENT OF CURSOR
END-EXEC
No fiddling around with INSPECT ... in order to get the length of the field
(sans trailing spaces), no need for the SQL RTRIM function, or any other
annoying workarounds.

Of course this almost seems a pipe dream. Even if, say, Micro Focus
implemented this feature, we'd still have to have IBM implement support for
it into the precompiler. (Or does MF use it's own pre-compiler?)

I'd also love to see some kind of COBOL support for "null" values. Even
with the proposed COBOL 2008 features (of which ANY LENGTH PREFIXED is one)
I don't think there's anyway way to specify a field (other than an actual
pointer, of course), as having a value of "NULL". But I'd love to see it! I
know that C# has support for this. Never seen any other language with it,
though.

Back to the real world, though...
As someone else said, you can just use DAT OF LASTNAME (or DAT IN LASTNAME)
to uniquely qualify that field. (Again, I personally would love to use
LASTNAME.DAT).

Also, there is of course nothing that says you can't edit the output from
db2dclgn prior to using it. I personally would do that unless perhaps I had
several hundred columns and no time to fiddle around editing them. You only
have to do it once. As you add new fields you just put them into the
copybook by hand, maybe using db2dclgn to guide you to the proper PICTURE
and USAGE.

Hope this helps, and is accurate. As I said, I could be wrong about the IND
thing, but I believe I am correct.

Frank


---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA


.

Relevant Pages

  • Re: COBOL Compiler for Windows
    ... Do the MS and Fujitsu compilers support VSAM KSDS files? ... Cobol, though normally Cobol programs are used in a CICS service. ... SQL service is also not part of Cobol. ...
    (comp.lang.cobol)
  • Re: In answer to RW - again (was: Sorts (revised)
    ... I never said Cobol should support GUI. ... >many compilers, it is often done using one of a range of ... >pre-processors that convert the SQL into CALLs. ...
    (comp.lang.cobol)
  • Re: Definition of FACTORY
    ... > taking different elements in the record to create keys. ... COBOL provided nice syntactic file access support initially. ... the SQL part. ... > At a later stage, as need arises, I can include SQL syntax in other ...
    (comp.object)
  • Re: Conversion of data & associated logic from ISAM to RDB
    ... embedded SQL is not necessarily the best solution. ... feed it your ISAM COBOL definition (Source code) and it creates a Relational ... Database in third normal form. ...
    (comp.lang.cobol)
  • Re: Dynamiv SQL and multi-row access SQL from COBOL... some quick questions
    ... EXECUTE IMMEDIATE is for one time dynamic SQL. ... Perhaps you were referring to something other than host variables. ... COBOL using ACCESS 2003. ...
    (comp.lang.cobol)