John, To the best of my knowledge, you are absolutely correct regarding the syntactical limitation (or lack thereof) regarding PDS member names, the length limitation is "baked in" but other then not allowing 8x'FF' you are free to use anything you want for a member name :-)
The rules regarding PDS/E member name are different, but as I wrote in my prior append my best guess is that the Converter is using FIND/BLDL which are limited to 8 character member names (although not uppercase alphabetic and national characters). Having said that the limitation of using characters outside of uppercase alphabetic and national (#@$) characters in JCL for PROCs and INCLIUDEs (in my judgement) is predicated upon the parsing engine that the Converter has. Having written a parsing engine the prospect of "tinkering" with the Converter parser makes me very uncomfortable :-( I'm not saying it can't be done or even that it shouldn't be done but my discomfiture puts it further down my (personal) priority list :-) John McDowell <snip> >I always thought that the 8 character limit was due to the natural limit of >PDS member names. Seems reasonable to retain this due to the "pain" of >trying to increase it. But I am certain that FIND / BLDL is in no way >restricted to upper case alphabetics only. SMP/E maintained PDS libraries >contain really weird (unprintable hex) member names with _no_ problems. And >I'm as certain as I can be without having access to the source that SMP/E >uses standard BPAM for most of its functions. There is no documentation in >the DFSMS manuals about not using any hex value, other than 8x'FF', as a >member name. John McDowell ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
