RE: convert dds to ddl -- MIDRANGE-L

ok let me try again. (apparently these Lortabs are kicking in lol)

if you retrieve a select/omit LF source as an INDEX - the select/omit
references are lost but the key field criteria will be there.(and that's
why you submitted a DCR...again thanks it needs to be fixed for 6.1 and
higher). IF you retrieve the select/omit LF as a VIEW - you'll get the
select/omit criteria but no key.

by default in Ops Nav using generate SQL against a LF of *any* type
(select/omit, or simply keyed) the API is called in a fashion to generate
the SQL as a CREATE VIEW rather than a CREATE INDEX. hopefully that's
more clear...but then again with the brain fog who knows?

Thanks,
Tommy Holden

From: "Crispin" <cbates@xxxxxxxxxxx>
To: "'Midrange Systems Technical Discussion'"
<midrange-l@xxxxxxxxxxxx>
Date: 08/06/2010 03:23 PM
Subject: RE: convert dds to ddl
Sent by: midrange-l-bounces@xxxxxxxxxxxx

Tommy,

I think Select/Omit is a completely different discussion to Joins.
Select/Omit LF's are easily replaced with DDL because of RCDFMT and WHERE
being added to CREATE INDEX at 6.1.

I don't understand

"the select/omit LFs are also VIEW when retrieved"

followed by

"i assumed you meant that *all* LFs were retrieved as VIEWs instead of
INDEX, hence my reply."

Just what are you saying :)

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Tommy.Holden@xxxxxxxxxxxxxxxxxxxxx
Sent: Friday, August 06, 2010 3:18 PM
To: Midrange Systems Technical Discussion
Subject: Re: convert dds to ddl

not saying there's no frustrations. the select/omit LFs fall under the
caveats i briefly mentioned with an example being join LFs. the
select/omit LFs are also VIEW when retrieved. and BTW thanks for
submitting the DCR. i assumed you meant that *all* LFs were retrieved as
VIEWs instead of INDEX, hence my reply.

Thanks,
Tommy Holden

From: "Crispin Bates" <cbates@xxxxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Date: 08/06/2010 02:12 PM
Subject: Re: convert dds to ddl
Sent by: midrange-l-bounces@xxxxxxxxxxxx

Tommy,

Have you actually tried this on an LF with Select/Omit Criteria. I can
guarantee you that you will not get a WHERE clause (I have a DCREQ open
for
it). So, it is the API that is at fault, because it will not give you DDL
with a WHERE clause when you specify INDEX and therefore doesn't live up
to
it's claims (of being able to generate DDL for DDS objects).

Who decided that DDS LF's were only ever VIEW's has...I'll stop there
before
I raise my blood pressure.

When I first loaded 6.1, I was not getting RCDFMT either, and had to get a

PTF for that. So, I think my frustrations are founded :)

----- Original Message -----
From: <Tommy.Holden@xxxxxxxxxxxxxxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Sent: Friday, August 06, 2010 2:58 PM
Subject: Re: convert dds to ddl

the API will allow you to retrieve the DDS LF as an INDEX...but you have
to tell the API that you want the output to be an index rather than a VIEW
(which for some unknown reason is the default. i never use Navigator for
this type of thing so it may not be an option there. with the GENDDL
command that interfaces with that API you can specify that is should
retrieve an INDEX statement rather than a VIEW. of course you have the
same caveats with join LFs, etc. but that will get you the majority of
what you are after. in a nutshell, it's not the API that has the issue
it's how it's being called from within Ops Nav

Thanks,
Tommy Holden

From: "Crispin Bates" <cbates@xxxxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Date: 08/06/2010 01:42 PM
Subject: Re: convert dds to ddl
Sent by: midrange-l-bounces@xxxxxxxxxxxx

My frustrations with QSQGNDDL showing through :)

----- Original Message -----
From: "Birgitta Hauser" <Hauser@xxxxxxxxxxxxxxx>
To: "'Midrange Systems Technical Discussion'" <midrange-l@xxxxxxxxxxxx>
Sent: Friday, August 06, 2010 2:18 PM
Subject: AW: convert dds to ddl

I knew it, every time if I think I do not have to mention something
someone
points me to it ;)

I'd not use generate SQL to create SQL scripts for indexes and/or views.
I used generate SQL it to get SQL scripts for our DDS described physical
files. But we did not only translate 1:1, instead we added an identity
column to each of the new "physical files" and generated primary key
constraints over the identity column. That will allow us to implement
referential integrities (sometime in future).

Long ago we searched through all our logical files, found the different
key
combinations, generated SQL indexes and replaced the DDS described logical
files in our F-Specs.
Unused logical files were removed after. With each new release we could
replace more DDS described logical files. Currently there are only left a
few keyed join files that are used in some F-Specs.

Mit freundlichen Grüßen / Best regards

Birgitta Hauser

"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"