Impacts of modifying record structures

pablo grim pablow666@gorge.net
Mon, 23 Jul 2001 14:28:00 -0700


The temp item has not changed.

Calling screen:

TEMP T-NEW-ENTRY         CHAR*1     RESET AT STARTUP INIT "N"

Called screen:

TEMP T-NEW-ENTRY     CHAR*1

I should mention that I did NOT execute the UNLOAD/CREATE/RELOAD procedure
on the affected record.  I don't usually do this unless the index structure
or record length has changed.

p




> From: "Edis, Bob" <bob.edis@fleetpride.com>
> Date: Mon, 23 Jul 2001 16:03:01 -0500
> To: "'powerh-l@list.swau.edu'" <powerh-l@lists.swau.edu>
> Subject: RE: Impacts of modifying record structures
> 
> Has the definition for T-NEW-ENTRY changed?   How is it declared on each
> screen?
> 
> I assume the receiving screen was always a MENU screen.
> 
> I tend to agree with a previous poster; you will have to recompile the
> screens that reference this record.
> 
> Blue
> 
> -----Original Message-----
> From: pablo grim [mailto:pablow666@gorge.net]
> Sent: Monday, July 23, 2001 3:54 PM
> To: Edis, Bob; 'powerh-l@list.swau.edu'
> Subject: Re: Impacts of modifying record structures
> 
> 
> Sure.  Here's a typical example:
> 
> 
> RUN SCREEN HRS_EXE:HRNK096.QKC MODE SAME PASSING EMPLOYEE-PER, T-NEW-ENTRY
> 
> SCREEN HRS_EXE:HRNK096.QKC  MENU RECEIVING EMPLOYEE-PER, T-NEW-ENTRY &
> MESSAGE ON 24
> 
> I tried the "substructure" approach on the record statement rather than
> shortening the filler field, but I am still getting the same error message.
> 
> Here are the items in question after substructuring.  The country code field
> is the new item.  CLIENT-ELEMENT is the filler item:
> 
> CLIENT-ELEMENT                       CHARACTER         40          295
> .FOREIGN-COUNTRY-CODE                CHARACTER          2          295
> DATE-LONGEVITY-LAST                  INTEGER SIGNED     4          335
> 
> The file is indexed sequential RMS.
> 
> Is there some way I could do it with a REDEF?  I am playing around with it,
> but it increases the record length...
> 
> tx
> 
> p
>> From: "Edis, Bob" <bob.edis@fleetpride.com>
>> Date: Mon, 23 Jul 2001 14:54:00 -0500
>> To: "'powerh-l@list.swau.edu'" <powerh-l@lists.swau.edu>
>> Subject: RE: Impacts of modifying record structures
>> 
>> Pablo
>> 
>> Can we see the subscreen/run screen statements from the calling screen and
>> the screen statement from the receiving screen please?
>> 
>> Regards,
>> Blue
>> 
>> -----Original Message-----
>> From: pablo grim [mailto:pablow666@gorge.net]
>> Sent: Monday, July 23, 2001 2:42 PM
>> To: powerhouse
>> Subject: Impacts of modifying record structures
>> 
>> 
>> Howdy folks,
>> 
>> Ok, I have a record structure called EMPLOYEE-PER that is used in about a
>> zillion programs.  The record structure includes "filler" fields for
> future
>> expansion.  This is handy to avoid having to recompile everything when
>> adding a new item to the record structure.  Simply take some bytes from
> the
>> filler and use them for the new item.  Therefore, the record length stays
>> the same.  I'm sure most of you have done something similar.
>> 
>> Well, I did this, but I'm getting the error:
>> 
>> *d* The screen linkage parameters don't agree with local definitions.
>> 
>> when I call a subscreen passing the EMPLOYEE-PER record.  This is
>> disappointing as it looks like I will have to recompile every subscreen
> that
>> receives this record structure as a parameter (a very significant task).
> I
>> don't remember this happening before when using this old tried and true
>> technique for avoiding recompiles.  Is this something new?
>> 
>> Does anybody have any suggestions for modifying my record structure
> without
>> having to recompile?  All I am trying to do is add a new 2 character field
>> to the record.  The "filler" field that I have shortened is not a
> parameter
>> being passed to the subscreens.
>> 
>> VMS 7.1
>> PH    7.10
>> RMS files
>> 
>> thanks!
>> 
>> p 
>> 
>> = = = = = = = = = = = = = = = = = = = = = = = = = = = =
>> Mailing list: powerh-l@lists.swau.edu
>> Subscribe: "subscribe" in message body to powerh-l-request@lists.swau.edu
>> Unsubscribe: "unsubscribe" in message body to
>> powerh-l-request@lists.swau.edu
>> http://lists.swau.edu/mailman/listinfo/powerh-l
>> This list is closed, thus to post to the list you must be a subscriber.
>> 
>> = = = = = = = = = = = = = = = = = = = = = = = = = = = =
>> Mailing list: powerh-l@lists.swau.edu
>> Subscribe: "subscribe" in message body to powerh-l-request@lists.swau.edu
>> Unsubscribe: "unsubscribe" in message body to
> powerh-l-request@lists.swau.edu
>> http://lists.swau.edu/mailman/listinfo/powerh-l
>> This list is closed, thus to post to the list you must be a subscriber.
> 
> = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> Mailing list: powerh-l@lists.swau.edu
> Subscribe: "subscribe" in message body to powerh-l-request@lists.swau.edu
> Unsubscribe: "unsubscribe" in message body to powerh-l-request@lists.swau.edu
> http://lists.swau.edu/mailman/listinfo/powerh-l
> This list is closed, thus to post to the list you must be a subscriber.