In my decades of MV programming, the manuals have gotten more scarce. I recall the original Microdata manuals being pretty good but not perfect enough. Thus JES was borne with their 'Pocket Guides' and other training periphery.
I have total dislike for the UV/UD manuals as they break up the commands by their stolen names for the obvious. UniBasic, UniQuery and ECL etc clearly have their roots as Data/Basic, English and TCL. Plus many commands are somewhat ambiguous and until recently, you struggle to determine which specific book to pick up to review its index to find the topic. MVBase is similar. At least the D3 manual had one single index so that SYSTEM (as a file name) is right next to SYSTEM() as a basic function and you can go from there. Nowadays, it should be easier and kept up to date far more easily with on-line docs. In the big picture, programmer's documentation can't be that much of a profit center so the principals may not want to invest too heavily there. A lot of this stagnation helps me believe that there is no future development on the database side, just rather keeping the flame and putting out fires (bugs). One could argue that since there is no real advancing of Proc (or other areas in the MV database) that the last real documentation (circa 1992?) may be all that we need. If you lived through it, as I and many have, then it's burned in our brains. If one is a new person to Pick, then there's the rub to rely on oldies like me or forums or other folklore. In a 'chicken and egg' situation, we should rely on each other and the forums for more real-world experience with the subtle nuances of these systems. I would bet that the vars like IBM and Raining Data (I know, TL) appreciate the relief of not having to spend $ on supporting the past. My free cents, Mark Johnson ----- Original Message ----- From: "Susan Lynch" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Saturday, August 02, 2008 1:46 PM Subject: Re: [U2] UniData PROC tip: DB command > Mark, > > A simple alternative to the "proc-to-Basic" convertor would be manuals - if > IBM would publish Proc and Paragraph manuals with the same level of > completeness that the Basic Reference manual has, there would be far less > frustration for the inheriting programmers. I 'grew up' on Microdatas and > Ultimates and Fujitsus and Sequoias and GA boxes, and never worked with > anyone who used Paragraphs until my current position. Now, not only are > there no Proc manuals (and procs behave somewhat differently than expected > from my past experience), but the Paragraph documentation does not come > anywhere near the level of complexity in the Paragraphs that I am > supporting, and I find myself frequently wondering what patches of Paragraph > code is doing. Why are we dependant on oral tradition (or threads like > this) rather than manuals for coding tools that are still functional? > > Susan Lynch > F.W. Davison & Company, Inc. > ----- Original Message ----- > From: "MAJ Programming" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: 08/02/2008 12:57 PM > Subject: Re: [U2] UniData PROC tip: DB command > > > > Martin: These are some holy grails that would be wonderful if found. > > > > One client of mine that was on Results (Microdata) then Universe and is > > now > > on D3, still has the original Results PQN procs. > > > > Fortunately those procs did not use the extended &, # and ! variable > > nomenclature but use the % nomenclature very often. Their solution > > attacked > > the MV command in this way: > > > > Original: > > MV %1 "Mark" > > New: > > HMV %1 "Mark" > > P > > > > whereby they had created a program called MV that would interpret the > > request. It uses PROCREAD/WRITE. The downside is that this databasic > > program > > could not interpet MV &1.4 %10 or MV #1 "SORT MD" as it had no access to > > those buffers. > > > > So one small step for mankind. > > > > Regarding "A" correlatives to I Descriptors. One of my clients uses Media > > Services Group's Advertising billing system and from the looks of the > > code, > > it used to be on R90 then Universe then now on Unidata. All of the > > dictionary items that used to be "A" correlatives had gone through a > > conversion utility to create the I descriptors. That utility saved on line > > 10 the original 10 line R90 dict item using IIRC value marks. Thus, the > > original dict item (for me to more easily understand) exists on the > > ignored > > line 10. > > > > I never got good at the interpreted version of I descriptors (NEQS, EQS > > and > > the nested command structure) so I assumed that the conversion was okay. I > > write CALL I descriptors if the dict item gets busy. > > > > I will offer this though. As a straight programmer for individual clients > > (not a VAR, reseller or employee at one location), it may not be worth it > > to > > 'fix what ain't broke' regarding replacing their working procs with all > > data/basic. > > > > But I think it would be a matter of uniformity and forward compliance for > > those VAR, reseller or employee-level members of this forum to engage in > > the > > project of replacing procs with programs. For the VAR's, it would be a > > continued investment in their product. For the employees, it would remove > > one of the legacy entities that may become harder to find younger > > programmers who can (or want to) understand Procs beyond the bvious > > jobstreams. > > > > My 3 cents > > Mark Johnson > > ----- Original Message ----- > > From: "Martin Phillips" <[EMAIL PROTECTED]> > > To: <[email protected]> > > Sent: Friday, August 01, 2008 2:56 PM > > Subject: Re: [U2] UniData PROC tip: DB command > > > > > >> Hi, > >> > >> > The man (person) who writes a PROC interpreter/conversion utility > >> > that can take a PROC and turn it into either Basic, or a PAragraph, > >> > will > >> > have a product to sell... esp. if it can decipher all the PROC nuances > > and > >> > tricks that have been introduced over the years. > >> > >> Back in the days when I was working on the development of PI/open, I had > >> a > >> go at this. It is not difficult to produce Basic code that does the same > > job > >> as the Proc but producing good code rather than a simple step by step > >> interpretation of the Proc is difficult. Also, there are some strange > >> interactions between Procs and the underlying command environment that > >> are > >> different from how Basic programs work so you can never get a true > >> replacement. > >> > >> > Same goes for a tool to convert A correlatives to I-descriptors. > >> > >> This is relatively easy. If you think there is a market, we might even do > >> it. We looked at this as part of the migration process for users moving > >> to > >> OpenQM but we chose to implement correlatives instead as it was easy. > >> Ours > >> are compiled (like an I-type) rather than interpretive for best > > performance > >> so actually the task of writing the convertor is probably little more > >> than > >> ripping apart our existing correlative compiler. > >> > >> > But pity the wretch that is assigned the task of writing the tool to > >> > convert > >> > F correlatives. > >> > >> This is probably easier than A correlatives. Again, if there is a real > >> market that would pay a sensible price for it, we might do it. > >> > >> > >> Martin Phillips > >> Ladybridge Systems Ltd > >> 17b Coldstream Lane, Hardingstone, Northampton, NN4 6DB > >> +44-(0)1604-709200 > >> ------- > >> u2-users mailing list > >> [email protected] > >> To unsubscribe please visit http://listserver.u2ug.org/ > > ------- > > u2-users mailing list > > [email protected] > > To unsubscribe please visit http://listserver.u2ug.org/ > ------- > u2-users mailing list > [email protected] > To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
