Index for item size

hy 

i use  the follwing select 

:select sgvar614 if a9999 eq "^^^"
[401] no items present.

but sometimes takes to long...  and i was think...

is possible create a index for that ...

for exemple CREATE-INDEX SGVAR614 A9999

it would continue acctin as funciction to size.. or would do as the attribute ?

------------------------------
Alberto Leal
System Analyst
Millano Distribuidora de Auto Pecas Ltda
Varzea Grande MT BR
------------------------------

Just tried it on my D3 Windows 10.3.3 and D3 Linux 10.2 systems. It will create the index, but the index doesn't work

list-index customers
customers 627663 a9999 Case Insensitive

:select customers with size > "120"
[401] no items present.

:delete-index customers a9999
Deleting index on a9999

:select customers with size > "120"
[404] 43 items selected out of 51 items.

Sorry.

------------------------------
Brian S. Cram
Principal Technical Support Engineer
Rocket Software
------------------------------

Just tried it on my D3 Windows 10.3.3 and D3 Linux 10.2 systems. It will create the index, but the index doesn't work

list-index customers
customers 627663 a9999 Case Insensitive

:select customers with size > "120"
[401] no items present.

:delete-index customers a9999
Deleting index on a9999

:select customers with size > "120"
[404] 43 items selected out of 51 items.

Sorry.

------------------------------
Brian S. Cram
Principal Technical Support Engineer
Rocket Software
------------------------------

yes... its creates as atribute and not as function...

select is to sloww haha

------------------------------
Alberto Leal
System Analyst
Millano Distribuidora de Auto Pecas Ltda
Varzea Grande MT BR
------------------------------

yes... its creates as atribute and not as function...

select is to sloww haha

------------------------------
Alberto Leal
System Analyst
Millano Distribuidora de Auto Pecas Ltda
Varzea Grande MT BR
------------------------------

Hola!
Just a thought:

Create a call routine which does an EXECUTE which is an access statement which produces the answer you want; capture the result, strip out the junk [Headers, footers etc etc] returning the number you want. Attach that to a dictionary item if necessary [because I cannot be bothered testing this idea, lol]

Then either create an index using the call routine; or dictionary item. I forget the exact mechanism for doing so, but I can leave that to you.

:>)

David

------------------------------
David Knight
Managing Director
Matash Australia Pty Ltd
AU
------------------------------

Hola!
Just a thought:

Create a call routine which does an EXECUTE which is an access statement which produces the answer you want; capture the result, strip out the junk [Headers, footers etc etc] returning the number you want. Attach that to a dictionary item if necessary [because I cannot be bothered testing this idea, lol]

Then either create an index using the call routine; or dictionary item. I forget the exact mechanism for doing so, but I can leave that to you.

:>)

David

------------------------------
David Knight
Managing Director
Matash Australia Pty Ltd
AU
------------------------------

Thanks David..

that was what i was thinking to do, but how ??

------------------------------
Alberto Leal
System Analyst
Millano Distribuidora de Auto Pecas Ltda
Varzea Grande MT BR
------------------------------

Thanks David..

that was what i was thinking to do, but how ??

------------------------------
Alberto Leal
System Analyst
Millano Distribuidora de Auto Pecas Ltda
Varzea Grande MT BR
------------------------------

Hi Alberto,
I've done this before; but do not have ready access to that code right now, but I can give you a guide:

I assume you've made flashed call/callx type routines before? If not, there are reasonable examples [I think] in the d3 manual.

But a 'typical' s/r would like like this [the syntax is likely wrong; but you get the idea]:

ITEMSIZE

SUBROUTINE ITEMSIZE(SIZE)
*
* Routine to return the itemsize of the record so it can be indexed.
* Change MYFILE as appropriate below
*
THIS.KEY = ACCESS(10)
RETURNVAL = 0
*
EXECUTE.STRING  = /LIST MYFILE = '/
EXECUTE.STRING := THIS.KEY
EXECUTE.STRING := /' a9999 (bchijk/
*
EXECUTE EXECUTE.STRING CAPTURING AQLDATA RETURNING RETVAL
*
SIZE =  AQLDATA<2>
*
RETURN
*****************************************************************************

Still not sure how build the dictionary and index itself, so shall leave you to muck around with that part.

Cheers!

David

------------------------------
David Knight
Managing Director
Matash Australia Pty Ltd
AU
------------------------------

Hi Alberto,
I've done this before; but do not have ready access to that code right now, but I can give you a guide:

I assume you've made flashed call/callx type routines before? If not, there are reasonable examples [I think] in the d3 manual.

But a 'typical' s/r would like like this [the syntax is likely wrong; but you get the idea]:

ITEMSIZE

SUBROUTINE ITEMSIZE(SIZE)
*
* Routine to return the itemsize of the record so it can be indexed.
* Change MYFILE as appropriate below
*
THIS.KEY = ACCESS(10)
RETURNVAL = 0
*
EXECUTE.STRING  = /LIST MYFILE = '/
EXECUTE.STRING := THIS.KEY
EXECUTE.STRING := /' a9999 (bchijk/
*
EXECUTE EXECUTE.STRING CAPTURING AQLDATA RETURNING RETVAL
*
SIZE =  AQLDATA<2>
*
RETURN
*****************************************************************************

Still not sure how build the dictionary and index itself, so shall leave you to muck around with that part.

Cheers!

David

------------------------------
David Knight
Managing Director
Matash Australia Pty Ltd
AU
------------------------------

Hi Alberto,
I think I have an idea on how to help you but I want to make sure I understand the issue correctly.

I looks like you are trying to get the count of "values" in attribute 9999 of the "sgvar614" file.
Is this correct?

If this is correct:
What does the data in the values look like? Specifically, do the data values contain spaces?
If there are spaces then the method changes and more program steps are necessary which increases processing time.
Will there be blank data values?
If there are blank data values should they be counted?

Attribute examples:
a]b]c]d Would have a count of 4
]b]c] If blanks are counted would still have a count of 4
]b]c] If blanks are NOT counted would have a count of 2

------------------------------
Lance Mcmillin
Sr Programmer Analyst
Health Advocates
Sherman Oaks CA US
------------------------------

Hi Alberto,
I think I have an idea on how to help you but I want to make sure I understand the issue correctly.

I looks like you are trying to get the count of "values" in attribute 9999 of the "sgvar614" file.
Is this correct?

If this is correct:
What does the data in the values look like? Specifically, do the data values contain spaces?
If there are spaces then the method changes and more program steps are necessary which increases processing time.
Will there be blank data values?
If there are blank data values should they be counted?

Attribute examples:
a]b]c]d Would have a count of 4
]b]c] If blanks are counted would still have a count of 4
]b]c] If blanks are NOT counted would have a count of 2

------------------------------
Lance Mcmillin
Sr Programmer Analyst
Health Advocates
Sherman Oaks CA US
------------------------------

Hy...

no Lance.. that atribute

a9999

its a special atribute from d3 that show the size of the item 

https://www3.rocketsoftware.com/rocketd3/support/documentation/d3nt/102/refman/ATTRIBUTEDEFININGITEM/asterisk_a9999.htm#reference169

------------------------------
Alberto Leal
System Analyst
Millano Distribuidora de Auto Pecas Ltda
Varzea Grande MT BR
------------------------------

Hy...

no Lance.. that atribute

a9999

its a special atribute from d3 that show the size of the item 

https://www3.rocketsoftware.com/rocketd3/support/documentation/d3nt/102/refman/ATTRIBUTEDEFININGITEM/asterisk_a9999.htm#reference169

------------------------------
Alberto Leal
System Analyst
Millano Distribuidora de Auto Pecas Ltda
Varzea Grande MT BR
------------------------------

Hi,
This is interesting...
After some testing, there seems to be an problem with the value that "a9999" returns as the record size.
At least if by record size we mean the number of characters actually stored in the record.

I created a test record named "A" in a testfile "TEMPLCM" that contains a single character in the record - a capital Z
Both of these commands return record lengths of 13:
I created a program RECSIZE
Returns a value of 1, correctly

Here is where it gets interesting.
This command returns 1 for RECSIZE and 8 for a9999
In all cases a9999 seems to be returning some value that seems to be padded, though I cannot figure out where the extra 7 or 12 characters are coming from...

When i add a second line to the "A" record that contains a Y, the RECSIZE value increased, correctly, to 3 and the a9999 value stays at 8 when I list both RECSIZE and a9999.
When I list just a9999 it returns 15.

Brian, can you shed any light on this discrepancy?

Alberto,
I think your goal is to find a fast way to select records based on total record size (length).

I think I would create a second file, that would hold the sizes of the records in the first file.
You could create a pre-write trigger in the first file that writes the record length to the second file in attribute one using the record id from the first file as the record id for the second file.

Selects on the new second file should be really fast and an index shouldn't be necessary, though you could create one if really necessary.
Since the record ID's are the same, any resultant select list from the second file will work on the first file.

I believe your pre-write trigger program should look something like this:
I believe the "Named" common will hold the file open if you are doing a mass update to multiple records.
I don't know if I have ever used that construct in a trigger so I'm not sure exactly how it would work. Brian may have a better idea.

If you don't want a second file, you could conceivably designate an attribute in the first file and have the pre-write trigger modify "item" before writing. This would result in the actual length of the record contains the record length value...

Hope this helps.





------------------------------
Lance Mcmillin
Sr Programmer Analyst
Health Advocates
Sherman Oaks CA US
------------------------------

Hi,
This is interesting...
After some testing, there seems to be an problem with the value that "a9999" returns as the record size.
At least if by record size we mean the number of characters actually stored in the record.

I created a test record named "A" in a testfile "TEMPLCM" that contains a single character in the record - a capital Z
Both of these commands return record lengths of 13:

LIST TEMPLCM a9999

LIST TEMPLCM "A" a9999

I created a program RECSIZE

SUBROUTINE RECSIZE( RESULT )

REC = ACCESS( 3 )

RESULT = LEN( REC )

RETURN

This command

LIST TEMPLCM RECSIZE

Returns a value of 1, correctly

Here is where it gets interesting.
This command returns 1 for RECSIZE and 8 for a9999

LIST TEMPLCM RECSIZE a9999

In all cases a9999 seems to be returning some value that seems to be padded, though I cannot figure out where the extra 7 or 12 characters are coming from...

When i add a second line to the "A" record that contains a Y, the RECSIZE value increased, correctly, to 3 and the a9999 value stays at 8 when I list both RECSIZE and a9999.
When I list just a9999 it returns 15.

Brian, can you shed any light on this discrepancy?

Alberto,
I think your goal is to find a fast way to select records based on total record size (length).

I think I would create a second file, that would hold the sizes of the records in the first file.
You could create a pre-write trigger in the first file that writes the record length to the second file in attribute one using the record id from the first file as the record id for the second file.

Selects on the new second file should be really fast and an index shouldn't be necessary, though you could create one if really necessary.
Since the record ID's are the same, any resultant select list from the second file will work on the first file.

I believe your pre-write trigger program should look something like this:

SUBROUTINE PREWRITE_TRIGGER( item )

COMMON /FILE2/ file2

IF NOT( ASSIGNED( file2 ) ) THEN

OPEN '{FILE2 NAME HERE}' TO file2 ELSE STOP

END

recid = ACCESS( 10 )

reclen = LEN( item )

WRITE reclen ON file2, recid

RETURN

I believe the "Named" common will hold the file open if you are doing a mass update to multiple records.
I don't know if I have ever used that construct in a trigger so I'm not sure exactly how it would work. Brian may have a better idea.

If you don't want a second file, you could conceivably designate an attribute in the first file and have the pre-write trigger modify "item" before writing. This would result in the actual length of the record contains the record length value...

Hope this helps.





------------------------------
Lance Mcmillin
Sr Programmer Analyst
Health Advocates
Sherman Oaks CA US
------------------------------

Hi Lance,
The discrepancy in size is due to the fact that a9999 returns all the space an item takes up, this includes the 8 byte item header, attribute marks, and ending segment mark.  If you dump the frame in which the item resides you would see something like this:
fid: 309659 : 0 0 0 0 ( 4B99B : 0 0 0 0 )
0000 00000000 0D001001 41FE5AFE FFFFFFFF 000 :........A^Z^____:
8 byte item header
Item ID
Attribute Mark
Value of attribute 1
Attribute Mark
Segment Mark
An item is properly terminated with an attribute mark and a segment mark, these are included in the count returned by a9999.

Hope that helps.

------------------------------
Chris Macadam
Technical Support Engineer
Rocket Software
------------------------------