This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C113B4.1B371400 Content-Type: text/plain; charset="iso-8859-1" Seen this one a thousand times it seems... You're in great shape UNTIL you PASS the record structure. PowerHouse is only "part-smart" about that part. It seems that it can handle the new elements directly referenced, but as part of the compilation of the passing/receiving clause it takes a count of the number of elements in the record. If you change that, then all the screens passing/receiving the record will fail, while everything else will continue to work just tickety-boo. We ended up creating a separate system compile procedure to recompile just those screens for this exact purpose. Having said all that, the best practice (although the most risky depending on your program release protocol) is to recompile everything that affects the record that was changed. That way you won't have default values accidentally slotted into your new elements by an old program which explicitly loaded the FILLER field. Curtis Aikens Information Technologies Dairyland (780) 486-8442 -----Original Message----- From: pablo grim [mailto:pablow666@gorge.net] Sent: Monday, July 23, 2001 1: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. ------_=_NextPart_001_01C113B4.1B371400 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">RE: Impacts of modifying record structures Seen this one a thousand times it seems...
You're in great shape UNTIL you PASS the record = structure. PowerHouse is only "part-smart" about that = part. It seems that it can handle the new elements directly = referenced, but as part of the compilation of the passing/receiving = clause it takes a count of the number of elements in the record. = If you change that, then all the screens passing/receiving the record = will fail, while everything else will continue to work just = tickety-boo.
We ended up creating a separate system compile = procedure to recompile just those screens for this exact = purpose.
Having said all that, the best practice (although the = most risky depending on your program release protocol) is to recompile = everything that affects the record that was changed. That way you = won't have default values accidentally slotted into your new elements = by an old program which explicitly loaded the FILLER field.
Curtis Aikens
Information Technologies
Dairyland
(780) 486-8442-----Original Message-----
From: pablo grim [mailto:pablow666@gorge.net] =
Sent: Monday, July 23, 2001 1:42 = PM
To: powerhouse
Subject: = Impacts of modifying record structuresHowdy 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 filesthanks!
p
=3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D = =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D
------_=_NextPart_001_01C113B4.1B371400--
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.