- Community Home
- >
- Servers and Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Unable to link due to attribute SHORT - PASCAL
-
- Forums
-
- Advancing Life & Work
- Advantage EX
- Alliances
- Around the Storage Block
- HPE Ezmeral: Uncut
- OEM Solutions
- Servers & Systems: The Right Compute
- Tech Insights
- The Cloud Experience Everywhere
- HPE Blog, Austria, Germany & Switzerland
- Blog HPE, France
- HPE Blog, Italy
- HPE Blog, Japan
- HPE Blog, Middle East
- HPE Blog, Russia
- HPE Blog, Saudi Arabia
- HPE Blog, South Africa
- HPE Blog, UK & Ireland
-
Blogs
- Advancing Life & Work
- Advantage EX
- Alliances
- Around the Storage Block
- HPE Blog, Latin America
- HPE Blog, Middle East
- HPE Blog, Saudi Arabia
- HPE Blog, South Africa
- HPE Blog, UK & Ireland
- HPE Ezmeral: Uncut
- OEM Solutions
- Servers & Systems: The Right Compute
- Tech Insights
- The Cloud Experience Everywhere
-
Information
- Community
- Welcome
- Getting Started
- FAQ
- Ranking Overview
- Rules of Participation
- Tips and Tricks
- Resources
- Announcements
- Email us
- Feedback
- Information Libraries
- Integrated Systems
- Networking
- Servers
- Storage
- Other HPE Sites
- Support Center
- Aruba Airheads Community
- Enterprise.nxt
- HPE Dev Community
- Cloud28+ Community
- Marketplace
-
Forums
-
Blogs
-
Information
-
English
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
07-10-2015 01:12 PM
07-10-2015 01:12 PM
Re: Unable to link due to attribute SHORT - PASCAL
Is there any that chance that you can get rid of this COMMON-based position-dependent design, and replace it with private or global sections? COMMONs have always been, are now, and will be, a bag of hurt. Map the whole thing with a backing file, if that's necessary. Otherwise, this looks like you might have a bug in Pascal and that's going to involve the support center.
The Pascal equivalent of the C extern model is Alpha-specific, per the doc.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
07-13-2015 07:11 AM
07-13-2015 07:11 AM
SolutionThank you to everyone who has helped with this issue especially H.Becker for his identification of CD_COMMON$END as being in the normal section.
The fix for us was to move everything into COMMON and numbered the variables so they remained in the order we required.
We also created a PSECT with a packed byte array to line up the section to a page boundary.
If you do not line it on a page boundary then crmpsc syscall will fail with an invalid argument error
Examples below:
MEMORY_PAGE_TYPE = PACKED ARRAY [1 .. MEMORY_PAGE_LEN] OF BYTE;
** Start file **
SharedAreaStartAlign : [GLOBAL, VOLATILE, PSECT(CD_COMMON)] MEMORY_PAGE_TYPE;
SharedAreaStart : [GLOBAL, VOLATILE, COMMON(CD_COMMON_000)] INTEGER;
** CD_COMMON file **
CheckData : [GLOBAL, VOLATILE, COMMON(CD_COMMON_001)] CHECK_DATA_TYPE;
GlobalCreateTime : [GLOBAL, VOLATILE, COMMON(CD_COMMON_002)] DAI_TIME_TYPE;
** End file **
SharedAreaEnd : [GLOBAL, VOLATILE, COMMON(CD_COMMON_999)] MEMORY_PAGE_TYPE;
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
07-14-2015 01:59 PM
07-14-2015 01:59 PM
Re: Unable to link due to attribute SHORT - PASCAL
Just to wrap up what I found when I had access to an I64 with Pascal installed. If you have source modules like
$ type %.pas DISK$USER:[USER]A.PAS;1 module a; var start : [global,psect(cd_common)] integer; end. DISK$USER:[USER]B.PAS;1 module b; var whatever : [global,psect(cd_common)] integer; data : [global,psect(cd_common)] array [1..2048] of integer; end. DISK$USER:[USER]C.PAS;1 module c; var last : [global,psect(cd_common)] array [1..2000] of integer; end. $ $ pas a $ pas b $ pas c
You end up with short data sections in a.obj and b.obj:
$ pipe analyze/obj %.obj |search sys$pipe common 5. NOBITS CD_COMMON 00000000000000F0 0000000000000004 WA------Sho------------------- 5. NOBITS CD_COMMON 00000000000000F0 0000000000002008 WA------Sho------------------- 5. NOBITS CD_COMMON 00000000000000F0 0000000000001F40 WA---------------------------- $
It seems like Pascal determines whether the data should be in a short data section based on the first variable in a module with attributes, specifiying the PSECT name.
I didn't find any other attribute to force data out of short data and there seems to be no directive or qualifier to avoid short data. Given the SOLITARY option for the linker, some code may expect the first data (here variable start) being on a page boundary. So what can be done is to make the first variables bigger than "short" - prefix with unused data in module a and change the sequence in module b:
$ ty a.pas module a; var unused : [global,psect(cd_common)] array [1..8192] of char; start : [global,psect(cd_common)] integer; end. $ ty b.pas module b; var data : [global,psect(cd_common)] array [1..2048] of integer; whatever : [global,psect(cd_common)] integer; end. $ pas a $ pas b $ pipe analyze/obj %.obj |search sys$pipe common 5. NOBITS CD_COMMON 00000000000000F0 0000000000002008 WA---------------------------- 5. NOBITS CD_COMMON 00000000000000F0 0000000000002008 WA---------------------------- 5. NOBITS CD_COMMON 00000000000000F0 0000000000001F40 WA---------------------------- $
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
07-14-2015 07:50 PM
07-14-2015 07:50 PM
Re: Unable to link due to attribute SHORT - PASCAL
I'd have hoped that multiple modules mapping to the same common data would have identical definitions of that data, which would presumably mean that the PSECT attributes would be the same?
To have anything other than identical definitions (and preferably a single source of text, using whatever langauge constructs are available), is setting yourself up for errors somewhere sometime. I present this post as evidence!
I'd have further hoped that in 21st century, we'd be using better, safer data sharing mechanisms than overlaid common blocks. That you have to fiddle around with dummy variables to align things in the right place should be ringing alarm bells that it's not a good way to achieve your objectives.
This is a good illustration of the general rule "never lie to a compiler". When a compiler gets conflicting descriptions of the same object, it shouldn't be surprising that it generates conflicting implementations of that object.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
07-15-2015 12:49 AM
07-15-2015 12:49 AM
Re: Unable to link due to attribute SHORT - PASCAL
> I'd have hoped that multiple modules mapping to the same common data would have identical definitions of that data, which would presumably mean that the PSECT attributes would be the same?
Common data? There is no COMMON in my example other than the misleading name CD_COMMON. A COMMON is different and has different attributes, like:
$ ty x.pas module x; var start : [global,common(psect)] integer; end. $
Yeah, just for fun I gave the COMMON the misleading name PSECT.
$ pas x $ pipe analyze/object x |search sys$pipe psect 6. NOBITS PSECT 00000000000000F0 0000000000000004 WA------------GblOvr---------- $
And, as you can see, this will not go into short data and the section has the PSECT attribute OVR.
> I'd have further hoped that in 21st century, we'd be using better, safer data sharing mechanisms than overlaid common blocks.
The OP said this is a port from Alpha, which has the 21 in the processor model numbers but not automagically in the SW designs :-) Who knows, maybe the SW was written for VAX. And who knows what the reasons were to port this code to I64 - but very likely there was some hope that the port would be easy and would not require a re-design or re-write.
> This is a good illustration of the general rule "never lie to a compiler".
Probably true, but I can't see that the rule was violated, here.
That said and not knowing why this code was written that way, no question, I would have written it differently - or maybe would have lied differently :-)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
07-15-2015 04:23 AM
07-15-2015 04:23 AM
Re: Unable to link due to attribute SHORT - PASCAL
Thanks once again H.Becker for your continued help.
We have now changed it all back to how it was and then changed the start value in CD_COMMON$START from an integer to a packed array oy bytes that is exactly a page long.
This has then put all of the variables into a normal section and with much less work to change the code.
To give some idea as to why this mechanism is still used in the 12st century it is because the software was originally for vax before moving to microvax and then alpha.
During each migration we make a few changes as possible for stability reasons.
We do not ever force our customers to upgrade to the latest version of our software and due to the industry we work in it is VERY important that we do not do that.
Our new systems work differently than these old systems but are only available for Linux / AIX
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
07-15-2015 12:33 PM
07-15-2015 12:33 PM
Re: Unable to link due to attribute SHORT - PASCAL
Gee, I don't look here for a week and along comes a Pascal question. Nobody thought to email me?
Yes, Harmut figured it out. The first variable placed in the PSECT determines the 'shortness'. That is a bug which I thought I described in the release notes about the time I transitioned off of the VMS compilers. Looking back, we should have extended the PSECT attribute to make the shortness explicit.
Adding something to the front that is larger than 8 bytes should do the trick. I can fix it on the VSI compiler side. I can't speak for HP.
I'll also update the release notes.
- « Previous
-
- 1
- 2
- Next »
Hewlett Packard Enterprise International
- Communities
- HPE Blogs and Forum
© Copyright 2021 Hewlett Packard Enterprise Development LP