Re: corrupt zip files
On Sun, 6 May 2012 12:40:29 -0500, Bill Godfrey yak36...@yahoo.com wrote: On Sat, 5 May 2012 08:54:52 -0500, Paul Edwards wrote: Most likely the original byte was x'14' which is also quite common in this location in zip files. In code page 437 and its cousins, x'14' is the paragraph sign. In iso9959-1 and many of its cousins, x'b6' is the same paragraph sign. In 437, x'15' is the section symbol. In iso8859-1, x'a7' is the same section symbol. Your occurrence counts show there are no x'14' or x'15', but among the few characters occurring above x'7f' are x'b6' and x'a7'. I would guess that at least two separate things happened to the file at different times. First, all the high-order bits were turned off. Later, a translation was done as if the data was presumed to be in code page 437, which converted x'14' and x'15' to x'b6' and x'a7', resulting in some values having the high-order bit set. Something else happened, either at the same time or not, that changed a few other characters to other values that have the high-order bit set, for which I have no explanation. Thanks Bill. That is the best working theory I have seen to date. Unfortunately it doesn't look like I will be provided an opportunity to get to the bottom of this, because the person who sent it has already sent a proper replacement, and is not interested beyond that. BFN. Paul. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
corrupt zip files
I have a zip file that appears to have been produced using pkzip for z/OS. However, it looks like it has been transmitted using some sort of text protocol, because the high bit has been stripped from most bytes, and some other bytes appear to have been translated. e.g. I think x'0a' in the input file has been mangled to x'b6' on the way. Does anyone know what software would do a translation like that? I believe these characters: 0A 1060 0D 0 12 1044 14 0 15 0 1C 0 1E 0 24 1030 7F 0 are being mapped to these: 81 576 9C 361 A7 645 B6 527 BF 284 E0 249 E9 644 F2 718 Except for x'0d' which I think is just being deleted. This belief comes from counting (see below) occurrences of the various bytes in a largish (80k) file. Here is a small file that shows the problem: 00 504B0304 B6000600 08006455 22405746 PKdU@WF That x'b6' above should be x'0a' I think (that's more normal). Apparently some protocol doesn't think that x'0a' will make it through, so translates it in advance. 10 30447A00 2802 0800 5851 0Dz...(...XQ 20 46303130 38313510 310A4330 0C447740 F010815.1.C0.Dw@ ... A0 504B0102 780BB600 06000800 64552240 PK..x...dU@ B0 57463044 7A00 2802 08003401 WF0Dz...(.4. C0 0100 5851 ..XQ D0 46303130 38316500 30016973 7976 F01081e.0.isyp.. This x'69737970' is really (once high bit is added back) x'E9F3F9F0' ie 'Z390' ie something that pkzip for z/OS inserts. E0 00014000 00050002 1600 04022800 ..@...(. F0 06005C00 08000700 0501 00070006 ..\. 000100 4B00 05000740 004B 00064462 ..K@.@Db 000110 52707073 40404040 40404040 40404040 Rpps 000120 40404040 40404040 40400A @@. Does anyone have any idea what protocol (ftp, sftp, winscp, kermit, connect:direct, http) would affect data in this manner? I've never seen mangling like that before. Thanks. Paul. 00 594 01 698 02 740 03 488 04 749 05 697 06 536 07 526 08 545 09 854 0A 1060 0B 597 0C 641 0D 0 0E 608 0F 639 10 817 11 679 12 1044 13 641 14 0 15 0 16 621 17 533 18 554 19 611 1A 517 1B 555 1C 0 1D 612 1E 0 1F 639 20 731 21 592 22 607 23 549 24 1030 25 546 26 565 27 618 28 490 29 602 2A 436 2B 684 2C 629 2D 706 2E 589 2F 667 30 547 31 815 32 670 33 530 34 569 35 598 36 570 37 619 38 723 39 572 3A 508 3B 626 3C 676 3D 626 3E 615 3F 621 40 687 41 598 42 636 43 557 44 752 45 579 46 645 47 813 48 849 49 837 4A 617 4B 563 4C 587 4D 532 4E 618 4F 705 50 538 51 541 52 553 53 573 54 467 55 416 56 653 57 681 58 727 59 599 5A 560 5B 344 5C 611 5D 293 5E 663 5F 552 60 578 61 562 62 608 63 814 64 649 65 711 66 515 67 660 68 484 69 506 6A 528 6B 627 6C 773 6D 646 6E 627 6F 599 70 602 71 657 72 636 73 620 74 521 75 516 76 732 77 631 78 596 79 715 7A 551 7B 718 7C 621 7D 606 7E 630 7F 0 80 0 81 576 82 0 83 0 84 0 85 0 86 0 87 0 88 0 89 0 8A 0 8B 0 8C 0 8D 0 8E 0 8F 0 90 0 91 0 92 0 93 0 94 0 95 0 96 0 97 0 98 0 99 0 9A 0 9B 0 9C 361 9D 0 9E 0 9F 0 A0 0 A1 0 A2 0 A3 0 A4 0 A5 0 A6 0 A7 645 A8 0 A9 0 AA 0 AB 0 AC 0 AD 0 AE 0 AF 0 B0 0 B1 0 B2 0 B3 0 B4 0 B5 0 B6 527 B7 0 B8 0 B9 0 BA 0 BB 0 BC 0 BD 0 BE 0 BF 284 C0 0 C1 0 C2 0 C3 0 C4 0 C5 0 C6 0 C7 0 C8 0 C9 0 CA 0 CB 0 CC 0 CD 0 CE 0 CF 0 D0 0 D1 0 D2 0 D3 0 D4 0 D5 0 D6 0 D7 0 D8 0 D9 0 DA 0 DB 0 DC 0 DD 0 DE 0 DF 0 E0 249 E1 0 E2 0 E3 0 E4 0 E5 0 E6 0 E7 0 E8 0 E9 644 EA 0 EB 0 EC 0 ED 0 EE 0 EF 0 F0 0 F1 0 F2 718 F3 0 F4 0 F5 0 F6 0 F7 0 F8 0 F9 0 FA 0 FB 0 FC 0 FD 0 FE 0 FF 0 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: gcc (was: CBT Tape Version 482 has been cut)
I see about 12 MB and 14 MB zipped, respectively. very large more by OS/360 standards than by current-day laptop. How large unzipped and installed? About 100 MB. enable anyone with an MVS system, new or old, to compile and execute Does new or mean they're well tested on z/OS? z/OS is the primary target, and that's why it is distributed as an XMIT instead of a HET. It gets used and tested on z/OS, but development is mostly done on MVS/380. Are they Unix System Services-friendly (source, header, and object files)? GCCMVS is for MVS, not USS, and I don't know much about USS. However, Dave Pitts distributes something for USS. Are they GNU autoconf-friendly? I don't know what that entails. Are they, at least optionally, ASCII-friendly? (I.e. what does the preprocessor do for #if '0' == 48? z/OS C/C++ has at least an ASCII mode in which cpp says, yes. But the runtime libraries are incomplete.) There is much open-source software available which is difficult to deal with because of EBCDIC- centric compilers. An enormous effort has been made by multiple people in order to turn GCC into what you may call an EBCDIC-centric compiler. What runtime libraries are available? X11? Curses? Sockets? Others? Only the C standard library is provided. LE? Dave Pitts distributes something for that, but I'm not really familiar with that. My focus has been on ensuring that the basic compiler is able to be hosted on a pure MVS environment (not USS), and that it has a suitable C runtime library that conforms to the MVS rules so that you can write utilities, and that GCC should be one of those utilities, to allow for self-improvement. Actually my main interest is in improving the C runtime library. BFN. Paul. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: BCPii code
On Wed, 29 Dec 2010 11:11:10 -0600, Paul Gilmartin paulgboul...@aim.com wrote: How about a Public Domain C90 compiler? The compiler itself is freeware rather than PD. The C library is PD. I guess most people won't know/care about the distinction though. http://gccmvs.sourceforge.net/ From the discussion on that page, it appears to be mostly MVS 3.8 oriented. Given the effort that goes into making the package totally 31-bit clean for z/OS, I was surprised by this, and read the website, and have now updated it to try to make it clearer that z/OS is the primary target, and that MVS 3.8 (actually, I use MVS/380 for 31-bit) is (sort of) merely a means to that end. o Will it compile the samples in OA31731? Don't know. Do the samples conform to ISO/IEC 9899:1990? If so, yes. The samples aren't available for anonymous download. o Is it Unix System Services-friendly? Not the one I produce. It's MVS, not USS. There is an LE/370 target though if you rebuild from source. I don't know much about that though - Dave Pitts was the one who used the LE target. BFN. Paul. P.S. Sorry to hear about your economy drive, but that's the exact void that GCCMVS is designed to fill (ditto for CMS or VSE sites that struggle to cost-justify a compiler). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
PDOS/390
I've just uploaded a new version of PDOS/390 here: http://sourceforge.net/projects/pdos/files/pdos/pdos-stage67.zip/download This beta is far better than previous betas, and is actually good enough to allow GCC to self-compile under it. Obviously there's still a lot lacking, but that is at least one real-world task that PDOS/390 can do. And it does it with the natural filenames that GCC uses by default too. A lot of people downloaded the previous beta, but no reports of anyone successfully using it on real iron. It should be in with a shot at working on real iron so long as a telnet connection is used (ie it doesn't support 3270 currently). BFN. Paul. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PDOS/390
On Sun, 3 Oct 2010 09:35:34 -0500, Shmuel Metz (Seymour J.) shmuel+ibm-
m...@patriot.net wrote:
In listserv%201009261001091711.0...@bama.ua.edu, on 09/26/2010
at 10:01 AM, Paul Edwards mutazi...@gmail.com said:
2. This writes to a 3215 console (only), not 3270 - do
real machines typically have PC emulators attached
that can be made to emulate 3215?
No. Real machines had 1052-7, 3210 and 3215 devices back when they
were part of the operators' console, but once IBM switched to a 3270
interface they became much less common, and they were probably dead
long before the HMC came on the scene.
I have been told that telnet is effectively TN3215, even
though it's not called that.
Regardless, my app is doing a CCW x'09' (write with
automatic carriage return and CCW x'0A' (read inquiry).
I don't know what magic happens after the x'09' CCW
is executed, but surely a PC can handle this basic
line mode communication in lieu of the 3270
sophistication?
BFN. Paul.
P.S. some miscellaneous output from latest development ...
rem this is an example autoexec.bat
dir
echo about to run world
world aBc DeF
echo finished running world
echo
dumpblk 0 1 1
02:36:15 welcome to pcomm
02:36:15 pcomm is calling dir
02:36:15 SVC code is 120
02:36:15 SVC code is 42
02:36:15 got request to run DIR
02:36:15 parameter string is 0 bytes
02:36:15 PLOAD.SYS
02:36:15 PDOS.SYS
02:36:15 CONFIG.SYS
02:36:15 COMMAND.EXE
02:36:15 AUTOEXEC.BAT
02:36:15 WORLD.EXE
02:36:15 SVC code is 1
02:36:15 SVC code is 62
SVC code is 10
welcome to my world
argc = 3
arg 0 is
arg 1 is aBc
arg 2 is DeF
looping for a while
finished looping
SVC code is 10
SVC code is 120
SVC code is 120
SVC code is 20
SVC code is 120
SVC code is 10
SVC code is 10
SVC code is 120
SVC code is 120
SVC code is 20
SVC code is 120
SVC code is 10
SVC code is 10
SVC code is 120
SVC code is 120
SVC code is 20
SVC code is 120
SVC code is 10
SVC code is 120
SVC code is 120
SVC code is 3
SVC code is 1
SVC code is 62
SVC code is 10
rc from program is 5
finished running world
dumping cylinder 0, head 1, record 1
00 000C 8400
10
20
...
0003B0
0003C0
0003D0
0003E0
0003F0
000400 05C006C0 06C0D207 0078C058 D2070070 .{.{.{K...{.K...
000410 C060D207 0060C068 D2070068 C0701FAA {-K..-{.K...{...
000420 BFAF00B8 4130C078 50300048 4141 ..{. ..
000430 5850C048 4161 4172 9C00A000 .{..-..
000440 8200C050 4814 b.{
000450 020E 000C 84A4 ...u
000460 000E 0111 000E 0222
000470 000E 0333 07000498 4006 ...q ...
000480 3100049E 4005 08000480 ...
000490 06004814 20007FFF 0001 ...
0004A0 00010200 5A50C120 BE57C091 41770001 !A...{j
0004B0 5970C124 4740C0C0 4171 41660001 ..A.. {{
0004C0 4270C0A2 BE63C09C BE63C0A0 41440001 ..{s..{...{.
0004D0 5940C128 4720C0E0 9C00A000 8200C050 . A...{\b.{
0004E0 8200C0E8 000C 84F8 b.{Y...8
0004F0 000E 0444 58D0C12C 4120 .}A.
000500 502D0004 182D5A20 C130502D 004C4110 .!.A.
000510 C13858F0 C13405EF 8200C0F0 A..0A...b.{0
000520 4814 0004 0028 0008
000530 0078 0800 053C
000540 0004 0010 D7C4D7C3 D3C9C25A PDPCLIB!
000550
000560
000570
000580
000590
0005A0
...
0007C0
0007D0
0007E0
0007F0 E9C1D7C3 D6D5E2D3 ZAPCONSL
000800 47F0F00C 067C7CC3 D9E3F000 90ECD00C .00..@@CRT0...}.
000810 18CF58FD 004C50DF 000450FD 000818DF .
000820 5AF0C030 50FD004C 47F0C034 !0{0{.
000830 0078 05C018B1 41CC 4120 .{..
000840 5020D048 4120D130 5020D04C 4170D068 .}...J..}..}.
000850 50E0D068 5830C0BA 1A235027 000C4120 \}...{
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives
PDOS/390
I have uploaded the latest alpha of my operating system PDOS/390 to here: https://sourceforge.net/projects/pdos/files/pdos/pdos-stage36.zip/download This is the real bit: Directory of C:\devel\pdos\s370 26/09/2010 07:28 PM 231,236 pdos00.199 which is a 3390-1 disk image for use under Hercules. There's a readme.txt in the same place (reproduced below). I am interested in the following: 1. Does this work on real hardware? ie real S/390,z10 or whatever. 2. This writes to a 3215 console (only), not 3270 - do real machines typically have PC emulators attached that can be made to emulate 3215? 3. Could someone make available an uncompressed DFDSS physical dump of this data so that Gerhard's DSSDUMP can be updated? 4. What transfer mechanisms really work for getting this data onto a real box? Thanks. Paul. Welcome to PDOS/390 (and friends). This distribution comes with the PDOS operating system installed on a 3390. You will need to dump the 3390-1 disk image (pdos00.199), restore it to a real 3390, then zap the SYS1.PDOS dataset at location 7FC. Note that there is an eyecatcher ZAPCONSL just before the location. 0007E0 E9C1D7C3 D6D5E2D3 *ZAPCONSL* 000800 47F0F00C 067C7CC3 D9E3F000 90ECD00C 18CF58FD 004C50DF 000450FD 000818DF *.00..@@CRT0..* The following JCL will do that: //ZAP JOB CLASS=C,REGION=0K //* //* zap a dataset //* //ZAP EXEC PGM=IMASPZAP //SYSPRINT DD SYSOUT=* //SYSLIB DD DSN=SYS1.PDOS,DISP=SHR,UNIT=SYSALLDA,VOL=SER=PDOS00 //SYSINDD * CCHHR 000101 VER 07FC REP 07FC 00010038 ABSDUMPT ALL /* //* // (the example sets the subchannel to x'10038') Options for dumping the data would be to run ADRDSSU on a Hercules system running z/OS, or there is also a CCKDDUMP/CCKDLOAD. I've never actually used either, as I don't have access to a real system. I'm hoping that DSSDUMP can also be enhanced to do a physical dump, but at time of writing, Gerhard is waiting on some sample dumps to be made available. Maybe dumping this data (uncompressed) with ADRDSSU would give him what he needs. Note that PDOS is expecting the console to be a 3215, not a 3270. Since real sites are expected to be using a PC emulator of some description, or perhaps telnet, it is unclear whether it is possible to get this to work in the real world, even assuming some of the programming shortcuts (ie not checking for device errors) work in the real world. Here is an example of how to define the disk under Hercules: 01b9 3390 dasd/pdos00.199 Although all the source code for PDOS is provided, the build script (doit.bat) makes use of some separately-packaged utilities. Also note that pdptop.mac is copied from pdp390.mac. Note that currently PDOS is only designed to load a single load module (PCOMM) and then terminate (which eventuates in a wait code of 444). PCOMM is a normal MVS load module doing normal MVS calls, but PDOS only supports a fraction of normal MVS calls (it's still in design/proof-of-concept stage, basically). Support/feedback can be obtained here: http://tech.groups.yahoo.com/group/hercules-os380/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
PDOS/380
Using Hercules/380, I have created a PDOS/380, intended to run MVS executables, under an interface more like MSDOS. It has 24-bit and 31-bit flavours. Main code consists of ... 500 lines of C ... http://pdos.cvs.sourceforge.net/viewvc/pdos/pdos/s370/pdos.c?view=markup and 300 lines of assembler ... http://pdos.cvs.sourceforge.net/viewvc/pdos/pdos/s370/pdossup.asm? view=markup Other code to support stand-alone programs is in PDPCLIB. It is working (see below) as far as proof of concept is concerned. If anyone would like to provide input into the design, now would be the best time, as it will get stuck in stone before too long. BFN. Paul. 22:40:33 * MSG FROM HERCULES: Welcome to PDOS!!! 22:40:33 * MSG FROM HERCULES: IPL device is 1b9 22:40:33 * MSG FROM HERCULES: PCOMM should reside on cylinder 2, head 0 of IPL device 22:40:33 * MSG FROM HERCULES: SVC code is 120 22:40:33 * MSG FROM HERCULES: SVC code is 120 22:40:33 * MSG FROM HERCULES: SVC code is 10 22:40:33 * MSG FROM HERCULES: SVC code is 120 22:40:33 * MSG FROM HERCULES: SVC code is 24 22:40:33 * MSG FROM HERCULES: SVC code is 64 22:40:33 * MSG FROM HERCULES: SVC code is 27 22:40:33 * MSG FROM HERCULES: SVC code is 22 22:40:33 * MSG FROM HERCULES: SVC code is 120 22:40:33 * MSG FROM HERCULES: SVC code is 120 22:40:33 * MSG FROM HERCULES: SVC code is 10 22:40:33 * MSG FROM HERCULES: SVC code is 10 22:40:33 * MSG FROM HERCULES: SVC code is 120 22:40:33 * MSG FROM HERCULES: SVC code is 24 22:40:33 * MSG FROM HERCULES: SVC code is 64 22:40:33 * MSG FROM HERCULES: SVC code is 27 22:40:33 * MSG FROM HERCULES: SVC code is 22 22:40:33 * MSG FROM HERCULES: SVC code is 120 22:40:33 * MSG FROM HERCULES: SVC code is 120 22:40:33 * MSG FROM HERCULES: SVC code is 10 22:40:33 * MSG FROM HERCULES: SVC code is 10 22:40:33 * MSG FROM HERCULES: SVC code is 120 22:40:33 * MSG FROM HERCULES: SVC code is 24 22:40:33 * MSG FROM HERCULES: SVC code is 64 22:40:33 * MSG FROM HERCULES: SVC code is 27 22:40:33 * MSG FROM HERCULES: SVC code is 22 22:40:33 * MSG FROM HERCULES: SVC code is 120 22:40:33 * MSG FROM HERCULES: SVC code is 120 22:40:33 * MSG FROM HERCULES: SVC code is 10 22:40:33 * MSG FROM HERCULES: welcome to pcomm 22:40:33 * MSG FROM HERCULES: argc = 3 22:40:33 * MSG FROM HERCULES: arg 0 is 22:40:33 * MSG FROM HERCULES: arg 1 is Hi 22:40:33 * MSG FROM HERCULES: arg 2 is There 22:40:33 * MSG FROM HERCULES: SVC code is 10 22:40:33 * MSG FROM HERCULES: SVC code is 120 22:40:33 * MSG FROM HERCULES: SVC code is 120 22:40:33 * MSG FROM HERCULES: SVC code is 20 22:40:33 * MSG FROM HERCULES: SVC code is 120 22:40:33 * MSG FROM HERCULES: SVC code is 10 22:40:33 * MSG FROM HERCULES: SVC code is 10 22:40:33 * MSG FROM HERCULES: SVC code is 120 22:40:33 * MSG FROM HERCULES: SVC code is 120 22:40:33 * MSG FROM HERCULES: SVC code is 20 22:40:33 * MSG FROM HERCULES: SVC code is 120 22:40:33 * MSG FROM HERCULES: SVC code is 10 22:40:33 * MSG FROM HERCULES: SVC code is 10 22:40:33 * MSG FROM HERCULES: SVC code is 120 22:40:33 * MSG FROM HERCULES: SVC code is 120 22:40:33 * MSG FROM HERCULES: SVC code is 20 22:40:33 * MSG FROM HERCULES: SVC code is 120 22:40:33 * MSG FROM HERCULES: SVC code is 10 22:40:33 * MSG FROM HERCULES: SVC code is 120 22:40:33 * MSG FROM HERCULES: SVC code is 120 22:40:33 * MSG FROM HERCULES: SVC code is 3 22:40:33 * MSG FROM HERCULES: return from PCOMM is 5 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SEASIK 1.0 released
On Wed, 9 Jun 2010 10:48:18 -0400, Gerhard Postpischil gerh...@valley.net wrote: On 6/9/2010 5:17 AM, Paul Edwards wrote: Don't look at me. IBM are the ones who created ftp with the RDW option, and I'm not the only user of that. You missed one crucial step - you zip the AWS file, and then ftp that. No, you missed the fact that IBM created a you-beaut ftp with RDW option, specifically for transporting binary VB files, which happens to be the natural form of the data itself (ie before any packaging like zip or XMIT etc is done). No worry about record format or boundaries, The worry has been transferred into a fairly custom tape-packaging facility. Which, surprise surprise, IBM also doesn't provide a standard utility for on the MVS side. But, at least IBM, via their ftp with RDW option, provides something for one leg of the journey. Hopefully now that they've gone that far, they'll realise there's another leg that isn't currently covered, hence the minimalist custom routine requirement (available from two different people, at least, and very simple to write regardless). You don't need to learn about the AWS tape format in order to write it. and a universal unzip is available on just about every PC, Mac, and other workstation these days. That much isn't a problem. The only source code that is actually mine, is this one: Sorry - if you distribute it, you own it G My problem is that I have online displays to examine files, with scrolling, updating, etc. that are geared to 80 bytes lines; to support VB I'd need a complete rewrite, plus horizontal scrolling (perhaps I'll steal Browse from ETPS?). Just use COPYFILE to copy from VB into FB80 before displaying. It will silently truncate any long lines. While you may consider 3350s dinosaurs or only fit for them, that perfectly describes the Hercules/MVS crowd. Very few of them are running without 3390 support. There are more people who will struggle to find a 3350 to restore to. And PDPCLIB is only one out of eight (or whatever), so the next one will be one-eighth in 3390 size g Pardon? BTW, I downloaded Jay's SYSCPK distribution, again with a few pains. His also lacks decent documentation, but at least some is on his site. Have you considered, at a minimum, adding a single PDS with the appropriate man members for each program? With products like SED etc, I only patched them to work on MVS, so am mainly focussed on producing executables. The original archive is available, and contains man pages in whatever format the (e.g.) Unix people decided to put them in, along with examples, known bugs, change logs or whatever. Often these people have made the documentation available on the web too. And there are mailing lists to ask questions about the product, and bug submission sites, and a bug report database. So it wasn't really my intention to get involved in any of that. I do provide documentation just pointing back to the archive that was used, and from there, you can decide what to do. I've never even read it myself. I either learnt from examples from Unix shell scripts, or type in sed without parameters to see the usage (ie EXEC PGM=SED,PARM='') or occasionally I do a search of the internet, usually looking for questions from humans, ie how do I make sed look for a real period instead of treating it as a character substitution. Having said that, if you want to wade through the existing documentation and point to something specific you want to appear in a specific dataset of specific RECFM on MVS, I can add that in. E.g. do you want the sed\doc\sed.1 added to SED.JCL(SED)? Looks like it will fit without truncation. It probably won't look very nice without being filtered through a man program though. Is there one of those on MVS or you just want to read the raw file? I also need to look at BWBASIC - it's not using PDPCLIB, and I Where on earth did you get the idea that it wasn't using PDPCLIB from? There is one unusual thing about BWBASIC though. The author was happy to incorporate all the MVS changes into the official distribution, and made me a developer on the sourceforge project. need to see how usable their MVS interface is (same problems with PDS and DCB support). Why am I not surprised you have the same problems? :-) Unless ... You mean you're using an old version of BWBASIC that doesn't have the latest PDPCLIB changes? The restore of SEASIK didn't give you a new version? I didn't package the new version properly? Have you looked at AFOX00? I noticed you posted the IFOX source - does that version match our system? I thought it did when I posted it, but now that I'm doing disassemblies, I have found that it doesn't. However, it's very close, and as of today I have just got IFOX41 IFOX42 verified, and built with ASMANY and tested and working. A bit of drama getting it tested though. I noticed that sys2.linklib was further up in the linklist than sys1.linklib so decided to target sys2.linklib instead
Re: SEASIK 1.0 released
On Mon, 7 Jun 2010 03:11:20 -0400, Gerhard Postpischil gerh...@valley.net wrote: There's good news and bad news g I've been trying to restore SEASIK since Friday, with no luck. 1) There is a design error in DSSREST. When I added the RDW code, I wrote the code so it only works when the block size is equal to the sum of the lengths of all RDWs (+4 if there is a BDW). When I use IND$FILE to restore, I get block boundaries unrelated to the RDW sizes. I started to fix this, but the code got more and more complicated, and failed after processing three thousand blocks. I decided to redo Scott's code to eliminate one intermediate buffer, and just use the input buffer directly. That fails on the second block, and I ran out of time. But once it works it will be faster than the old version. I also fixed some spelling errors (leng for length). Ok. I use the tape processing facility and block at RDW boundaries naturally. 2) If you weren't such a sadist, I could have had this restored on Friday. a) Use DSSDUMP to create an AWS or HET tape. b) zip it. c) ftp or upload to wherever. d) user runs DSSREST against the tape file and gets all the files. None of this IDCAMS and special utility crap. For a real mainframe, there is an AWS conversion utility to create a real tape between steps c) and d). Don't look at me. IBM are the ones who created ftp with the RDW option, and I'm not the only user of that. And the special utility is only required because IBM (again) neglected to provide a facility to reverse that. They will presumably fix that oversight one day. I've seen others complaining about that, and the need for a utility. This process has nothing to do with tapes, so there's no need to force a tape format file into the mix, any more than forcing in a CKD VTOC. I uploaded a new version of DSSREST as part of the DSSDMP tape. It's still in 3350 format (I'll change it to 3390 when you change .SOURCE files to FB/80 g). It restored the SEASIK files without a hitch, using slightly less memory and time. You've got to stop walking into these things. :-) The only source code that is actually mine, is this one: PDPCLIB.SOURCE SEASIK 10.160 PO FB 80 6160 1414 And you'll notice that not only is it FB80 as requested, it's even blocked at the universal block size. The reason it is this way is because I was programming in MVS while you were still knee-high to a grasshopper. Well, maybe that's an exaggeration. You must be looking at (my bundling of) source code from Unix type people, where they don't seem to have gotten the message about restricting the length of lines to 80 so that it fits onto a card. So anyway, where's my 3390 dump? I had to especially go and mount a 3350 disk just to load your new version (which works). Do you know how much those things weigh? My site has been all-3390 for WEEKS now (at least, pubicly-mounted). Just like all z/OS shops. Only dinosaurs still use 3350s. And I'm no dinosaur, even if I do still block at 6233 or less so that I can fit data onto even a 2314 if necessary. BFN. Paul. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SEASIK 1.0 released
On Mon, 31 May 2010 18:07:08 -0400, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In listserv%201005241706095284.0...@bama.ua.edu, on 05/24/2010 at 05:06 PM, Paul Edwards mutazi...@gmail.com said: Also GETLINE/PUTLINE are used in a TSO environment, so all programs automatically become command processors. I takes more than that to make them command processors. Are you talking about the parameter processing? They do that too. If that's still not enough to be a command procesor, then I'm probably using the wrong word. What's the word to describe a program that can be invoked from the TSO ready prompt, with parameters, and can have its output trapped in a CLIST with SYSOUTTRAP, so that from a user's perspective, it does exactly what they want? BFN. Paul. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SEASIK 1.0 released
Wow, what a lot of misses. *nix humor. This is after all an environment with a utility called grep and where processes fork in order to make children. No Charles, Gerhard is MVS through and through. Nothing to do with Unix. You're right about the SEA = C though. Well, it's certainly memorable. Not sure I understand where it comes from -- it looks like an acronym, but for what? No Zman, not an acronym. It had to fit into a 6-character volser though, being MVS. On Mon, 24 May 2010 21:25:46 -0400, Gerhard Postpischil gerh...@valley.net wrote: On 5/24/2010 8:38 PM, zMan wrote: Well, it's certainly memorable. Not sure I understand where it comes from -- it looks like an acronym, but for what? Paul asked me to suggest something, No, it was unsolicited: http://tech.groups.yahoo.com/group/hercules-os380/message/1391 If I were seriously planning on writing lots of c programs, I would create a new pack (e.g, SEASIK g), allocate a user catalog on it, put the GCC and PDPCLIB stuff on there, add some user source libraries, and keep it separate and easy to back up. In fact, I would have to say that I explicitly turned down your suggestion: http://tech.groups.yahoo.com/group/hercules-os380/message/1611 The actual packaging of the SEASIK disk can be decided later. It'll probably just be a normal Hercules image to start with, but may in the future be DFDSS. Either way, I think 3390s should be the way ahead. The universal blocksize remains so that they can be copied off if required. I hope you'll think long and hard about the disk name - I meant SEASIK to be an obvious joke, reflecting my opinion on unreadable languages g I know it was a joke, but I honestly don't think I could come up with something better than that. And it's cool having both sides of the story out there. So, you let me put C on MVS, and I'll agree to advertise the fact that this is a sick thing to do, even if I don't personally agree. :-) So long as the things I want to achieve are done, I don't mind if I have to wear a Daffy Duck costume while doing them. :-) BFN. Paul. P.S. And yes, I really am so sad that I spent more than an hour trying to find the message when both gmane and Yahoo search failed to pick up the oldest reference, despite the fact that that means I'm going to sleep at 2am, when I know I have a meeting at 7am. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SEASIK 1.0 released
I have just released SEASIK 1.0, which is (effectively) a DFDSS dump of a whole lot of C products, namely: GCC 3.2.3 MVS 8.0 PDPCLIB 3.00 BISON 1.35 MVS 4.0 BREXX 2.1.8 MVS 1.0 BWBASIC 2.50 MVS 1.0 DIFFUTIL 2.8.1 MVS 4.0 FLEX 2.5.4a MVS 4.0 M4 1.4 MVS 4.0 PATCH 2.5.4 MVS 4.0 SED 3.02 MVS 4.0 MINIZIP 0.15 MVS 4.0 These products are: GCCMVS - a C compiler PDPCLIB - a C runtime library BISON - a parser BREXX - a REXX interpreter BWBASIC - a Basic interpreter DIFFUTIL - programs such as diff3 to do a three-way diff FLEX - a parser M4 - a text-processing utility PATCH - used to apply patches to source code (from diff) SED - substitutes text MINIZIP - a zip-like utility GCCMVS is also available as a standalone XMIT. Also there is a CMS version. All available from here: http://gccmvs.sourceforge.net PDPCLIB is also available standalone from here: http://pdos.sourceforge.net Note that while z/OS is the primary target, most of the executables will work fine on any other flavor of MVS (from MVS 3.8j up). Special thanks to Gerhard Postpischil for the revamp of mvssupa.asm which is at the heart of every C program compiled in this manner and which means you are no longer forced to provide DCB information on your output files (while still having complete flexibility to do so). Also GETLINE/PUTLINE are used in a TSO environment, so all programs automatically become command processors. Please report any problems to: http://tech.groups.yahoo.com/group/hercules-os380/ BFN. Paul. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
PDPCLIB (GCC) on S/390
Hi all. PDPCLIB is the C runtime library for the GCC port to MVS. Within PDPCLIB, there are two assembler files - mvsstart and mvssupa that do all the interaction with MVS. Almost all the work is in mvssupa. That has recently been radically revamped, and I would like to get it: 1. Tested on S/390 (ie MVS/ESA, OS/390, or z/OS). 2. Peer-reviewed. There is stand-alone JCL here: http://mvs380.sourceforge.net/pdp390.txt I have tested it on an MVS/XA-like environment, but I want to see if the code will run RMODE ANY. Regarding the peer review, I'm not after radical changes to add great new features (that could be done another day though). I'm just after you should have checked for the return code here or you used an L instead of LA here one or two-line changes. I know a couple of people here are interested in GCCMVS on z/OS, so here's your chance to ensure you get (closer to) what you want. Note that not all the features you see in the assembler have been opened up to the public (since that requires a separate overhaul of the C code, which is done by people with a different skillset), but some really great improvements are: 1. You now have default DCB info for datasets. 2. GETLINE/PUTLINE are used for a proper TSO CP. The S370 (24-bit only) and S380 (24-bit code, 31-bit data) I am able to test myself (and they work), but I am unable to test the S390 (pure 31-bit) myself and would normally have to go through a 3rd party to do that, so I'm hoping someone here could do that as well as looking over the code. I'm expecting it to be released in a matter of weeks, and be bundled as part of a SEASIK DFDSS dump containing this plus a variety of other free software (DIFF3, PATCH, BISON etc). Thanks. Paul. P.S. Expected output: 00 93899585 40F14040 40404040 40404040 line 1 10 40404040 40404040 40404040 40404040 20 40404040 40404040 40404040 40404040 30 40404040 40404040 40404040 40404040 40 40404040 40404040 40404040 40404040 50 93899585 40818283 40404040 40404040 line abc 60 40404040 40404040 40404040 40404040 70 40404040 40404040 40404040 40404040 80 40404040 40404040 40404040 40404040 90 40404040 40404040 40404040 40404040 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
new mainframe software releases (C compiler mainly)
Jujitsu are pleased to announce the release of the following software: GCC 3.2.3 MVS 7.5 - GCC C compiler for z/OS, MVS/380, MVS/370. Delivered in xmit format. GCC 3.2.3 CMS 7.5 - GCC C compiler for z/VM, VM/380, VM/370. Delivered in vmarc format. PDPCLIB 2.00 - C (C90-compliant) runtime library for MVS (all flavours), CMS (all flavours), Windows 32, MSDOS, OS/2, Linux (new with this release), PDOS. Provided in source form only, but also delivered as part of GCCMVS and GCCCMS. Hercules/380 3.06 v6.0 - Used to run MVS/380. It now does S/380 even if you specify S/370, so that Hercgui will work. Now has native support for ftp-rdw files (ie files that have been transferred from z/OS using ftp with the RDW option), so that you can quickly get your files restored to a V dataset. Windows executables provided. Unix users need to compile from source. You can find the products at: http://gccmvs.sourceforge.net http://pdos.sourceforge.net http://mvs380.sourceforge.net (respectively). Initial documentation can be found in gccmvs.txt, pdpclib.txt and README.S380 respectively. Any comments/questions please post over at: http://tech.groups.yahoo.com/group/hercules-os380 where our complaint department is in operation 24 hours a day, even during Ramadan - may Allah have mercy on our souls. BFN. Paul. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
MVS/380 1.0 and VM/380 1.0 now available
The Hercules community is pleased to announce the availability of two new freely-available operating systems that provide 31-bit programming capability. Load modules can be developed and tested on these environments and the binaries work unchanged (and without requiring special alternate APIs or support modules etc) on their z/OS and z/VM big brothers. Both are available from: http://mvs380.sourceforge.net An example of such a 31-bit program is GCCMVS, the GCC C compiler (fully C90 compliant) ported to MVS and CMS, and it comes bundled with the operating systems. It is also available as a separate product suitable for direct loading on z/OS and z/VM. See here: http://gccmvs.sourceforge.net There's also a stack of useful utilities there, e.g. diff3 (a 3-way diff - one of the great breakthroughs in computer science). These utilities have been precompiled as part of MVS/380 and VM/380. The port of GCC is dependent on the public domain (not GPL) C runtime library PDPCLIB (also fully C90 compliant). That is available here: http://pdos.sourceforge.net Other utilities include bwBASIC, BREXX, bison, sed, flex, m4, patch, minizip. There are also specialized batch files to assist in targetting the mainframe platforms from a PC. The S/380 platforms have quite a lot of development activity taking place (e.g. a DFDSS-compatible dump program) to push these platforms forward. Come and join us over at: http://tech.groups.yahoo.com/group/hercules-os380 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
