Conference iosg::all-in-1_v30

    Audrey, hi,
    
    I'm just a humble programmer, by no means a guru, my comments come from
    an empirical understanding so if someone else wishes to correct me I
    hope they do.
    
    I believe that there is no unreasonable limit to the length of a named
    data segment as long as no individual line exceeds 80 characters. There
    is a limit to the size of the string passed to a /PRE_FUNCTION or
    /POST_FUNCTION qualifier. To get around this I use code like that in
    the following segment:
    
    ----------------------------------------------------------------------------
	;;.TYPE;;

	ARG
	/OVERLAY
	/PRE='XOP "~~PRE_FUNCTION~~"' 
	/POST='XOP "~~POST_FUNCTION~~"' 
	/HARD=OA$_TM_HRD_ENTER_ATTENDEE 
 
	;;~~PRE_FUNCTION~~;; 
 
	DECIMAL I \ 
	GET LOG$SCROLL = "" \ 
	FOR SCROLL DO WRITE DELETE SCROLL NUMBER = .NUMBER \ 
	.IF #FREESCAN_EDIT NES "" 
	 THEN FOR CAL$SCROLL_ATTENDEES 
	       DO WRITE ADD SCROLL NUMBER=.NUMBER, TEXT=.TEXT 
	 
	;;~~POST_FUNCTION~~;; 
 
	IFEXIT \ 
	FOR CAL$SCROLL_ATTENDEES 
	 DO WRITE DELETE FREESCAN$ATTENDEES NUMBER=.NUMBER \
	 COMPUTE #KEY = 1 \
	 FOR SCROLL
	  DO GET #USER=.TEXT:30 \\
	     .IF PROFIL.USER[#USER] NES ""
	      THEN WRITE ADD CAL$SCROLL_ATTENDEES NUMBER=#KEY, TEXT=#USER
	      ELSE FOR GROUP$:#USER
	            DO WRITE ADD CAL$SCROLL_ATTENDEES NUMBER=#KEY,
                                           TEXT=PROFIL:VMSUSR.USER[.VMSUSR] \\
	           .IF #USER NES "" THEN COMPUTE #KEY = #KEY + 1
    ---------------------------------------------------------------------------
    
    Note the ;;~~POST_FUNCTION~~;; code is longer than 256 characters.
    
    regards,
    ajb

	.1 is correct; there are only two restrictions to keep in mind.

	o  The length of a single Data element in Named Data is controlled by
FMS, not ALL-IN-1, and is one 80-character line.  This is the reason ALL-IN-1
created "overflow" lines in the first place, however, so the "restriction" is
purely a "readability" one.

	o  Literal character strings that need to be passed through internal
string routines are often ASCIC strings, meaning that their "count" cannot
exceed 255 characters.  Hence the limitation on some of the literals mentioned
in .1.  However, as any good programmer knows, if the only restriction on
something like a /PRE or /POST is the length of the string, you can always get
around that by either using the XOP function within the same Named Data, or
executing a script using the DO function.

	F

I too am interested in this limit.

Sometimes within named data you have to perform a complex BIND function, whose
RSE may be quite long.

Now does the 255 character limitation apply here too? I am using a BIND with
around 600 characters and it _appears_ to work. Some of the standard ALL-IN-1
code also has quite long BIND expressions.

Obviously you can't split an RSE into multiple XOPs!!!!!


mb

    The 256 limit applies only to the string that goes with a qualifier.
    So /POST, /PRE.... have limits. These can use an XOP as said a couple
    of times before. If it is not a qualifier string then there is a limit
    of 64K or so.... ie no real limit.
    
    Rick

Rick,


	Thats great news, thanks for clarifying the limit,

	cheers,

	mb

    There used to be an artificial limit on the number of named data items
    if you use the E ND option, due to a limit in the executable that
    converts the text to named data.  Is that still around; I know it was
    increased in a previous version.
    
    Ben

    I believe that the limit was raised a little higher in V3.0, probably
    due to the expansion in the named data on some of the EM/WP index
    forms.  I seem to recall seeing a figure of 3000 lines somewhere.
    
    Tony