Re: DDS vs DDL. Record format level -- MIDRANGE-L

If the allocation is 0 then the base overhead area is only used if the
actual string length is 16 bytes (or something like that) or less.
Otherwise (if greater than "16") the system needs the overhead area to
address the longer string value and none of the the string value would go
in the base. But again this is something from ages ago (could well be the
same sixteen years you referenced lol).

On Wed, Oct 18, 2017 at 4:23 PM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
wrote:

Hi Bruce

The stuff in the base record is anything shorter than the allocated length
- any value longer than that length is stored as a pointer and/or some
index (it's been 16 years since digging into this!!) that points at the
auxiliary space.

Seems to me that what you describe doesn't help performance, cuz anything
longer than 16 would have 2 IOs to get the data - the main space always has
to be read, last I heard.

Sitting here knowing I could be wrong!!!

Vern

On 10/18/2017 3:54 PM, Bruce Vining wrote:

I'm going on really hazy memory here, but I seem to recall that variable
length strings less than (about) 16 bytes go into the base record. Within
the base record there is some overhead involved in accessing the variable
length data when not in the base. For small strings the system just
re-uses
some of this overhead area. So even if you say allocate none the system
will protect you (from performance penalties) when it can.

On Wed, Oct 18, 2017 at 3:19 PM, Charles Wilt <charles.wilt@xxxxxxxxx>
wrote:

Variable length field -- Allocated length : None

Is shown by DSPFFD for both...so no.

In addition, the default value for the DDS field is '' (empty)

I thought that perhaps it was one or even 40 spaces, but testing proved
that not to be the case.

It appears to me to be a bug...

Charles

On Wed, Oct 18, 2017 at 2:14 PM, Paul Therrien <
paultherrien@xxxxxxxxxxxxxxxxxx> wrote:

Very recently someone mentioned on this site that the default field size

allocated on an sql varchar field is set to 0 (zero); (or some very
small size).

Would there be differences in the way DDL and DDS handle varchar fields
that would cause the different record format level numbers?

Paul

On 2017-10-18 16:08, Troy Hyde wrote:

Nathan,

"I have long questioned the relevance of converting existing

DDS-defined

to

DDL-defined files while attempting to maintain the same Level ID. Okay,

it

can be done in most cases. But what value do you expect to gain?"

Not a ton of gain and none from the RPG/server side. Our GUI

application

is

written in Java using Hibernate. Our Java programmers are experiencing

an

issue that has to do with the SQL cache that they claim is a non-issue

for

SQL tables. This is another attempt to resolve a problem I actually
inquired on (very poorly) several years ago.
https://archive.midrange.com/midrange-l/201303/msg00417.html

----
To answer some of the other notes/questions:

Running 7.2

I get no errors running the SQL to create the table. I get the

identical

table source when I use the ACS wizard as I did with the QSQGNDDL api.

Regarding the api, I have a hard time believing that's the issue.

Whether

the SQL used to created the table is generated by ACS, the api or

pulled

out of the air, the resulting table is going to be the same:

For those interested here's some snipped source:

A UNIQUE
A R LASECVF
A SVAPNO 6S 0
A SVMODL 40 VARLEN
A K SVAPNO

Results:
Format level identifier . . . . . . . . . . : 21BBD4C3F064B
Number of fields . . . . . . . . . . . . . : 2
Record length . . . . . . . . . . . . . . . : 48

SQL code:
CREATE TABLE MYLIB/LASECV (
SVAPNO NUMERIC(6, 0) NOT NULL DEFAULT 0 ,
SVMODL VARCHAR(40) CCSID 37 NOT NULL DEFAULT '',
PRIMARY KEY( SVAPNO ) )
RCDFMT LASECVF ;

Results:
Format level identifier . . . . . . . . . . : 21BBD4C3F0E53
Number of fields . . . . . . . . . . . . . : 2
Record length . . . . . . . . . . . . . . . : 48

SQL code:
CREATE TABLE MYLIB/LASECV (
SVAPNO NUMERIC(6, 0) NOT NULL DEFAULT 0 ,
SVMODL VARCHAR(40) CCSID 37 NOT NULL , (removed

default)

PRIMARY KEY( SVAPNO ) )

RCDFMT LASECVF ;

Results:
Format level identifier . . . . . . . . . . : 21BBD4C3F4E93
Number of fields . . . . . . . . . . . . . : 2
Record length . . . . . . . . . . . . . . . : 48

In addition, I can change leave "Default 0" or "Default '' for char and
numeric columns and it doesn't make a difference.

TROY HYDE, Upgrades and Standards Manager

FLEX : 800 262 3539

Troy.Hyde@xxxxxxxxxxx

Confidentiality Notice: This communication and any associated

attachments

is intended only for the person or entity to which it is addressed and

may

contain information that is privileged, confidential or otherwise

protected

from disclosure. Dissemination, distribution or copying of this
communication and any accompanying attached information by anyone other
than the intended recipient(s), or an employee or agent acting on

behalf

of

the intended recipient, is strictly prohibited. If you have received

this

communication in error, please notify us immediately by replying to

this

message, and then delete it from your computer.

Subject: Re: DDS vs DDL. Record format level On Tue, Oct 17, 2017 at

7:53 PM, Troy Hyde <troy.hyde@xxxxxxxxxxx> wrote:

I've got a handful of DDS physical files, some that have existed since

the late 80s, that I'm converting to DDL.

I have long questioned the relevance of converting existing DDS-defined

to

DDL-defined files while attempting to maintain the same Level ID. Okay,

it

can be done in most cases. But what value do you expect to gain?

I've never viewed DDS and DDL to be mutually exclusive. I see value in
both. I'm aware of people who preach DDL vs. DDS. To each their own.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD

--

This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD