Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

how I can know the number of records in a key sequence file enscribe, from C or TAL?

481 views
Skip to first unread message

francisco lopez Chile

unread,
Sep 5, 2012, 4:20:48 PM9/5/12
to
My friends I have this problem, after making a FUP LOAD command from C program trought (ZSPI FUP), the process ZSPI does not deliver the records loaded by FUP LOAD.
can someone help me.

regars
Francisco




Keith Dick

unread,
Sep 5, 2012, 5:44:43 PM9/5/12
to
A quick look at the documentation indicates that FUP is supposed to return the count in the SPI response to the LOAD command. Did you overlook this, or do you mean that FUP is not doing what the documentation says it does? If the LOAD ended with an error, I imagine the count might not be included, but I believe it should be there if the LOAD ended normally.

The documentation I am looking at says that the response will contain one ZFUP-MAP-LOAD-XFER-COUNTS token (or ZFUP-MAP-LOAD-XFER-CNTS token -- it is spelled both ways in the manual) for each partition loaded. You should be able to retrieve all those tokens from the response and add their count fields to get the total number of records loaded.

If you want to check the response to see what it contains, the Inspect command

DISPLAY <buffer-name> TYPE SPI

will format the entire contents of the SPI message in <buffer-name> in an easily-readable form. If the FUP developers created a formatting templates file, the output will even show the names of the tokens in the buffer. If they did not create a formatting templates file, the token-ids will be displayed in numeric format. If you can't use command-line INSPECT for debugging because you are using an Itanium system, Visual Inspect can display SPI messages nicely-formatted, but I don't know how you request that from Visual Inspect. Check the Visual Inspect online help to see how to do it.

wbreidbach

unread,
Sep 6, 2012, 1:15:47 AM9/6/12
to kd...@acm.org
I just had a quick look at the manual and it seems that the token ZFUP-MAP-LOAD-XFER-COUNTS (or ZFUP-MAP-LOAD-XFER-CNTS) is contained in a datalist so the first thing you have to do is finding the datalist token
ssgettkn (buffer,zspi^tkn^datalist,,1)
to get the contents of the datalist.
I am only using the FUP SPI interface for reloading files so my experience with that SPI interface is somewhat limited. But I ran into that datalist problem at some other places like lines.

Keith Dick

unread,
Sep 6, 2012, 1:39:57 AM9/6/12
to
The SPI rules say that the response tokens are supposed to be contained within a datalist only when the command requests multiple responses per reply message. My quick look at the manual indicates that FUP follows those rules. I assumed the presence of the datalist tokens in the documentation of the LOAD command was an attempt to remind the reader that when multiple responses are requested, the responses will be enclosed within datalists.

It really doesn't make a lot of sense to request multiple responses per reply for a LOAD command, but, if the LOAD command requests multiple responses, FUP should put the single response within a datalist. I don't believe the documentation should show the datalist tokens in the documentation of individual responses, but this writer seemed to think it was a good idea to do so.

I think my suggestion to use Inspect or Visual Inspect to display the SPI response message in nicely-formatted form would very quickly show what the response actually contains. Then, if it isn't clear to Francisco how to proceed, he can tell us more about the situation and we can offer better suggestions.

wbreidbach

unread,
Sep 6, 2012, 2:05:23 AM9/6/12
to kd...@acm.org
In general you are right, Keith. But from my experience I know that not everything has been implemented according to these rules and unfortunately not every information in the manuals is correct. I wrote a bunch of programs using the SPI-interfaces of most of the NonStop subsystems and the behaviour of those SPI-interfaces is definitely different. The idea of having a look at the response buffer is a pretty good solution, I solved my problems the same way.

Keith Dick

unread,
Sep 6, 2012, 2:19:27 AM9/6/12
to
You certainly have had more experience trying to use the SPI interfaces than I have, so I'm sure you are right that some of them do not follow all the rules. I hope this discussion helps Francisco figure out what FUP is doing so he can get the record count.

Sjay

unread,
Sep 6, 2012, 5:41:44 AM9/6/12
to kd...@acm.org
I have a question.

Can I via a program, know, how many records an Entry sequenced file contains without using Fup?

Anupam Das

unread,
Sep 6, 2012, 5:47:28 AM9/6/12
to kd...@acm.org
On Thursday, September 6, 2012 3:11:44 PM UTC+5:30, Sjay wrote:
> I have a question. Can I via a program, know, how many records an Entry sequenced file contains without using Fup?

Sure! Whay not? Use Guardian Procedure calls instead of opening channel to FUP.

Thanks.

wbreidbach

unread,
Sep 6, 2012, 6:00:17 AM9/6/12
to kd...@acm.org
Just one hint to that:
Of course you can do it by program, just read all the records and count them. But you have to be aware that the FUP INFO...,STAT is much faster because it is using a buffered unstructured read. If you want to do something like that I recommend reading the ENSCRIBE manual which contains all the necessary information.

Anupam Das

unread,
Sep 6, 2012, 7:48:50 AM9/6/12
to kd...@acm.org
On Thursday, September 6, 2012 3:30:17 PM UTC+5:30, wbreidbach wrote:
>>Of course you can do it by program, just read all the records and count them. But you have to be aware that the FUP INFO...,STAT is much faster because it is using a buffered unstructured read. If you want to do something like that I recommend reading the ENSCRIBE manual which contains all the necessary information.<<

Hmmm...but are you saying FUP *reads* the file first before displaying the number of records? I don't think so. Label will have it anyways as it is of type Structured.

Tone

unread,
Sep 6, 2012, 8:03:02 AM9/6/12
to
Each block of a structured contains a count of the number of records in
that block, but there is no record count stored in the file label
regardless of whether the file is structured or unstructured.

Anupam Das

unread,
Sep 6, 2012, 8:16:51 AM9/6/12
to
On Thursday, September 6, 2012 5:33:04 PM UTC+5:30, Tone wrote:
>>Each block of a structured contains a count of the number of records in that block, but there is no record count stored in the file label regardless of whether the file is structured or unstructured.<<

Tone, I think we should re-validate this info from GNSC. I am an ex-DP2 programmer and we used to read file-label information where I am almost 100% sure I have seen the record count.

wbreidbach

unread,
Sep 6, 2012, 8:46:13 AM9/6/12
to
Try FUP INFO STAT on a big file and it will take its time, so the number on records cannot be in the label.
On the other hand imagine every insert and every delete would require an update to the header, you would have conflicts over conflicts. The manual states that every block contains the information about its number of records and I am very sure that FUP reads this information. I wrote a program analyzing the fragmentation of a KS file and I am doing it that way and the performance of that program is very similar to FUP.

Tone

unread,
Sep 6, 2012, 8:52:19 AM9/6/12
to
Actually I work in the GNSC and support DP2 and there is no API call
that will return the number of records in a file nor is there a field in
the file label that contains such a count.

Doug Miller

unread,
Sep 6, 2012, 11:16:12 PM9/6/12
to
Sjay <suhai...@gmail.com> wrote in
news:0d4372b7-8bcd-4d59...@googlegroups.com:

> I have a question.
>
> Can I via a program, know, how many records an Entry sequenced
> file contains without using Fup?

Yes, you can.

The block header of each block gives a count of the records in that block. Open the file in
unstructured mode, read the block headers, and add up the counts. It's way faster than
reading every record in structured mode and counting them.

Frans Jongma

unread,
Sep 7, 2012, 3:33:46 AM9/7/12
to
Thanks for confirming Tone.

Maybe a bit out of context here ... but SQL/MX 3.x actually maintains
a row count per partition in the file label. Only for tables created after 3.x
though.
The SQL API is SELECT ROW COUNT FROM <table_name>;
Note that there is no WHERE clause though :-). But finding how many rows are
in a table is really fast.



Tone

unread,
Sep 7, 2012, 9:43:07 AM9/7/12
to
Yes, true. However, probably worth mentioning that there are currently
limitations to the implementation (documented in the SQL/MX Reference
Manual). For example, cannot return a valid count for tables created via
DUP or RESTORE.

francisco lopez Chile

unread,
Jun 12, 2013, 4:03:33 PM6/12/13
to
Hello everyone, hope you're well.I regret to inform you that the solution did not work. I could not enter the token ZFUP-MAP-LOAD-XFER-COUNTS in fup load buffer.also the datalist in fup response is always ZERO.

I never see the number of records loaded in Einspect time.


what alternative I can use to know how many records have uploaded the file "key sequence"

right now I'm reading the file in a sequential, count = count +1.
but this solution is very slow.

Anyone have a good example in C code or other language?

thanks you



2: xSpiBuffer = {
z_msgcode = -28,
z_buflen = 4096,
z_occurs = 122,
z_filler = "TANDEM \000\006D*\000\000C\000\000\000\a\b\376!\000\003\000\001\0
00\000D*\a\020\376F", '\000' <repeats 15 times>, "z\024\030\000\001\\\374DESA12B
CHILE F3120713\a\377\000\r\000 $desa08 amexdatapb20001a\000\000\000\000\000\000
\000\006\013\002\000\000\000\000 \200\200\000\000", ' ' <repeats 27 tim
es>, "\000\a\377\000\f\000. \377\377\377\377\377\377\377\377\377\377", '
' <repeats 24 times>, "\377\377\377\377\0044", '\000' <repeats 15 times>, "^zoss
eDL"...
}



Bill Honaker

unread,
Jun 12, 2013, 5:55:15 PM6/12/13
to
Have you considered issuing a FUP INFO <file>,STAT command and looking
for the value in the DATA level and the TOTAL RECS column?

This command reads through all of the Enscribe blocks and is many
orders of magnitude faster than reading a file a reord at a time.

Keith Dick

unread,
Jun 12, 2013, 10:48:57 PM6/12/13
to
That dump of the SPI buffer you included theoretically contains all the information we would need to tell you how to solve your problem, but I doubt any of us has the time to turn that raw dump of the buffer into a form we can readily interpret.

If you can use Visual Inspect, it has a way to display a SPI buffer in a nicely-formatted way that shows the tokens and their values. If that doesn't let you figure out how to get the count of records loaded from the response, I believe you can do a typical Windows copy and paste from the Visual Inspect window into a text document or into the body of a post to this group. (I have used copy and paste from the memory dump display of Visual Inspect, but I've never tried it from the variable display part of Visual Inspect.) Once we can see the structure of the response, we will be able to help you get the record count from it. I do not remember how you tell Visual Inspect to interpret the variable as a SPI message, but I recall hearing that it has a way to do so. Check the Help within Visual Inspect to see the various options you can use for displaying variables. One of them will interpret the variable as as SPI message.

The folks who converted gdb into eInspect left out that display-as-SPI feature. If your program is in C or pTAL, try compiling it with the TNS C compiler or the TAL compiler so you get a code 100 file that you can debug with Inspect rather than eInspect. If you can get the program to compile and run that way, then you can display the response buffer with the Inspect command:

D xSpiBuffer TYPE SPI

Again, if that display is not enough to show you how to get the record count out of the response, post the display of the buffer here and we'll help you.

wbreidbach

unread,
Jun 13, 2013, 1:49:09 AM6/13/13
to
Look for the first occurence of the token within the response buffer, that has to be specified explicitely, usually searching for the token is started at the actual position within the buffer, whereever that might be. Refer to the description of ssget to do that.
Reading one by one is slow, of course. Specifying buffered read should speed up reading significantly but, as mentioned before, read the file in unstructured mode block by block and use the "number of records within block" to count the records. You could even read 56k but in that case you would have to do the de-blocking yourself.
0 new messages