Question about GBLs file format

50 views
Skip to first unread message

Kevin Toppenberg

unread,
Jun 19, 2024, 9:28:28 AM (14 days ago) Jun 19
to Hardhats
I am trying to install LEX_2_147.GBLs as part of a KIDS patch install.  The first two lines look like this.

LEX*2.0*147/ICPT*6.0*113 Data~Format=5.S~
03 Dec 2023   9:32 PM   IRIS

The standard way to import globals is via ^%GI, and that routine opens the file as follows (this is from YottaDB code):

open:$principal'=%ZD %ZD:(readonly:rewind:stream:recordsize=2044:ichset="M":exception="goto noopen"):0

I have tried to create a set of tools that speeds up the patch installation process, and as part of that I made a ^TMGGI as a tool duplicates this function, but allows the file names / devices to be passed in etc.   My code is older, and it opens the file as follows:

   OPEN %ZD:(readonly:block=2048:record=2044:exception="GOTO EX"):0

I think my version is based off an older gtm version of %GI.

My problem is that  LEX_2_147.GBLs contains one line that is 3423 characters long, and it appears that READ's are not getting the entire line, and they everything gets out of sync.

Questions:
  • I have not had this problem before.  Has there been a change in the GBLs file format to allow longer lines?  I notice the header line contains "Data~Format=5.S~"  Does anyone know what format "5.S" means
  • I thought that when a record size was specified, it was understood that each record was going to be the same number of bytes.  But the GBLs file has variable length lines.  So should recordsize even be specified?  The YottaDB documentation for recordsize says "Overrides the default record size for a disk".  Notice that the YottaDB version of the code has record size of 2044.  My line of 3423 chars is much longer than that.  does ^%GI restrict lines to 2044 chars?
  • My older code has record=2044, newer code has recordsize=2044.  Is "record" an allowed abbreviation for "recordsize"?  Does my code just have a bug?  Has something changed between gtm and yottadb?
  • Any suggestions?
Thanks in advance
Kevin

Kevin Toppenberg

unread,
Jun 19, 2024, 11:09:29 AM (14 days ago) Jun 19
to Hardhats
I decided to just remake my TMGGI based on the newer %GI and that works.  But if anyone knows the answers to my other questions, I would still appreciate the education.

KT

David Whitten

unread,
Jun 19, 2024, 8:55:05 PM (13 days ago) Jun 19
to hard...@googlegroups.com
The answers I have to your questions.

The %GI (or %GTI) format has two data lines followed by multiple
variable length lines in pairs.

The file is typically created by Do ^%GTO or DO ^%GO.

There are multiple "Global Dump programs that do not use the same
format, from multiple M implementations.

Some of those formats are very implementation specific.

The transportable format involves characters each of which is from
ASCII 32 through ASCII 127.

The repeated pairs of lines consist of a global reference, followed by
a data value.

The process must act as if it will be used as if a SET @FIRST=SECOND
command was performed.
It is also expected that the Naked Global Reference is set as it would
be if the SET occurred.

This means the text read as the first variable length string (FIRST)
could be a naked reference, and it could have M expressions as subscripts.
It cannot have control characters (ASCII 0 through 31 or any character
values larger than 126)
or Unicode characters in it.

The text read as the second variable (SECOND) must be the value of a M
variable.
It cannot have control characters (ASCII 0 through 31 or any character
values larger than 126)
or Unicode characters in it. The values of each character should not
be processed in any way.

There as some variations of the %GI format, notably marking the the
FIRST line with asterisks,
the word EOF or END OF FILE, but they don't conform to the format in
any of the ANSI MUMPS standards.

Dave Whitten
713-870-3834.
> --
> --
> http://groups.google.com/group/Hardhats
> To unsubscribe, send email to Hardhats+u...@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups "Hardhats" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to hardhats+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/hardhats/f9a3ad18-69ef-4776-8784-30b8e909aa89n%40googlegroups.com.

Sam Habiel

unread,
Jun 19, 2024, 10:18:55 PM (13 days ago) Jun 19
to hard...@googlegroups.com
  • > I have not had this problem before.  
  • > Has there been a change in the GBLs file format to allow longer lines?
  • As of Fileman 22.2, you can override the default 255 character length in M. Applications like the Lexicon slowly took advantage of this capability. I can't remember the limit now, but I think it may be 10,000 or 32,000.

  • > I thought that when a record size was specified, it was understood that each record was going to be the same number of bytes.  But the GBLs file has variable length lines.  So should recordsize even be specified?  The YottaDB documentation for recordsize says "Overrides the default record size for a disk".  Notice that the YottaDB version of the code has record size of 2044.  My line of 3423 chars is much longer than that.  does ^%GI restrict lines to 2044 chars? My older code has record=2044, newer code has recordsize=2044.  Is "record" an allowed abbreviation for "recordsize"?  Does my code just have a bug?  Has something changed between gtm and yottadb?

Kevin Toppenberg

unread,
Jun 20, 2024, 1:51:33 PM (13 days ago) Jun 20
to Hardhats
Thank you David,

When I look at the YottaDB ^%GI I see that it checks for two types of format.  One is what you mentions, and I think the other is a ZWR format.

Best wishes,

Kevin

Kevin Toppenberg

unread,
Jun 20, 2024, 1:52:28 PM (13 days ago) Jun 20
to Hardhats
Thank you for this reply.

The document referred to says:

^%GI accepts records up to the maximum string length (currently 1MiB). Previously it was limited to 8KiB for ZWR format and 2044 bytes for GO format. (GTM-8022) [!New Feature!]

This is helpful, thanks!


Kevin
Reply all
Reply to author
Forward
0 new messages